Google PCNE: Policy dei firewall, Cloud Armor e sicurezza di rete — Guida allo studio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Visibilità, ispezione e risposta agli incidenti

Osservabilità:

• I VPC Flow Logs forniscono record di flusso a 5 tuple campionati per sottorete, con campionamento, arricchimento dei metadati e intervalli di aggregazione configurabili. Utilizzali per la definizione di baseline delle prestazioni e il rilevamento delle anomalie.
• Il logging delle regole firewall acquisisce le autorizzazioni (allow) e le negazioni (deny) per singola connessione relative a regole specifiche con logging abilitato; crea regole di negazione esplicite per registrare i blocchi che altrimenti verrebbero gestiti dalle negazioni implicite.
• I log delle richieste e i risultati dell’anteprima di Cloud Armor mostrano le corrispondenze con le regole, le decisioni sulle azioni e gli esiti del rate-limiting a livello di edge.

Ispezione e rilevamento:

• Packet Mirroring copia il traffico verso un collettore nella stessa regione per la deep packet inspection o l’uso di un IDS. Definisci l’ambito del mirroring per sottorete, tag o service account per limitare l’overhead. Il packet mirroring è out-of-band e non blocca il traffico; utilizzalo con Cloud IDS o sensori di terze parti.
• L’ispezione L7 inline richiede un pattern di appliance a 2 NIC e l’instradamento del traffico attraverso di essa. Progetta per un routing simmetrico e alta disponibilità (HA); considera i domini di errore regionali e i potenziali colli di bottiglia nel throughput. I dispositivi inline aumentano il blast radius in caso di guasto; implementa gruppi di istanze gestite e pattern di failover delle route con health check, dove applicabile.

Pratiche di risposta agli incidenti:

• Centralizza i log in un progetto dedicato alla sicurezza, costruisci sistemi di rilevamento per picchi improvvisi di negazioni (deny), creazione di nuove regole ad alta priorità o attivazione dei rate limit di Cloud Armor. Utilizza BigQuery o integrazioni SIEM per le indagini.
• Assicura il principio del privilegio minimo (least-privilege) in IAM: il ruolo Network Admin non è sufficiente per modificare le policy firewall in una Shared VPC, dove è richiesto il ruolo Security Admin; separa le responsabilità tra i team di rete e di sicurezza.
• Quando hai bisogno di un accesso SSH di emergenza (break-glass) e le chiavi non sono pre-configurate, usa

undefined

da Cloud Shell per inviare una chiave effimera tramite i metadati dell’istanza, se consentito dalle impostazioni IAM e dei metadati dell’istanza.

• Per la risoluzione di problemi in scenari “senza log”: verifica la regola e la sua direzione, ricorda che le negazioni implicite non generano log e controlla le policy gerarchiche che potrebbero aver trovato una corrispondenza prima.

Scenario pratico

Contoso Retail gestisce una piattaforma web multi-tier su Google Cloud. Il traffico frontend è servito da un load balancer HTTP(S) esterno globale; le VM applicative sono eseguite in più regioni senza IP esterni. Il traffico in uscita (egress) deve passare in hairpin attraverso un NGFW di terze parti, ad eccezione delle API di Google (BigQuery e Pub/Sub). Il team di sicurezza desidera implementare guardrail a livello di organizzazione, allowlist di IP client per un progetto pilota con un partner e minimizzare i rischi durante il test di un client sospettato di essere dannoso.

Approccio:

1. Stabilire guardrail gerarchici

   • Creare una policy firewall gerarchica a livello di organizzazione che neghi tutto il traffico in ingresso (ingress) da 0.0.0.0/0 verso le VM di destinazione che non possiedono il tag di sicurezza env=public-entry, e che neghi le porte amministrative (SSH, RDP) da internet.
   • Motivazione: Impedisce l’esposizione non sicura a livello globale; gli sviluppatori non possono auto-assegnarsi il tag di sicurezza a causa delle autorizzazioni IAM sui tag.

2. Targeting dei workload basato sull’identità

   • Assegnare service account distinti ai tier di frontend, applicazione e database. Fare riferimento a questi service account nelle regole firewall a livello di VPC per consentire solo i flussi est-ovest necessari (ad esempio, frontend→app tcp:443, app→db tcp:5432).
   • Motivazione: Collega la policy all’identità del workload e previene l’uso improprio accidentale dei tag.

3. Regole di autorizzazione in ingresso (ingress) per i backend con load balancing

   • Sulle VM dell’applicazione, creare una regola di autorizzazione in ingresso (allow) ad alta priorità, indirizzata tramite il service account dell’app, con intervalli di origine (source) corrispondenti ai proxy Google Front End (GFE) e agli intervalli IP degli health check di Google; abilitare il logging.
   • Motivazione: Per il traffico HTTP(S) L7, i backend dovrebbero accettare connessioni solo dai GFE e dagli IP degli health check; le allowlist di IP client vengono applicate a livello di edge.

4. Policy di Cloud Armor a livello di edge

   • Associare una policy di Cloud Armor al servizio di backend del load balancer HTTP(S) esterno:
     • Aggiungere una regola di allowlist per gli IP dei client partner.
     • Abilitare le regole WAF preconfigurate per le OWASP Top 10.
     • Configurare un rate limit basato sull’IP del client con soglie conservative.
   • Motivazione: Applica restrizioni sulla sorgente del client e protezioni a livello di applicazione dove l’IP del client è visibile e prima che il traffico raggiunga la VPC.

5. Protezione adattiva e test sicuri

   • Abilitare Adaptive Protection e creare una regola di negazione (deny) per l’IP del client sospetto in modalità di anteprima (preview).
   • Motivazione: La modalità di anteprima consente la verifica del comportamento senza impattare gli utenti reali; i log confermano se il client è dannoso prima di applicare la regola in modo definitivo.

6. Segmentazione del traffico in uscita (egress) con Private Google Access

   • Mantenere una rotta 0.0.0.0/0 verso l’NGFW di terze parti. Aggiungere route statiche personalizzate per i VIP delle API di Google verso il gateway internet predefinito e abilitare Private Google Access sulle sottoreti. Aggiungere una regola esplicita di negazione totale (deny-all) del traffico in uscita ad alta priorità, seguita da regole di autorizzazione (allow) specifiche per il next-hop dell’NGFW e le API di Google; abilitare il logging.
   • Motivazione: Forza il traffico internet generico in uscita a passare attraverso l’NGFW, consentendo al contempo di raggiungere BigQuery e Pub/Sub privatamente senza inutili hairpinning.

7. Controlli su NAT e IP esterni

   • Utilizzare Cloud NAT per le istanze che necessitano di accesso a internet in uscita ma non hanno IP esterni. Eseguire un audit e rimuovere eventuali IP esterni dalle istanze di calcolo che devono utilizzare il NAT.
   • Motivazione: Previene il bypass del NAT e mantiene una singola postura di egress.

8. Ispezione e monitoraggio

   • Abilitare Packet Mirroring in ogni regione per il tier applicativo, indirizzandolo tramite il service account dell’app, e inviare il traffico specchiato a un collettore IDS regionale. Abilitare i VPC Flow Logs e il logging delle regole firewall per le regole chiave; esportare i log di Cloud Armor e della VPC in un progetto di sicurezza centralizzato e in BigQuery.
   • Motivazione: Fornisce una visibilità approfondita per il threat hunting e la definizione di baseline delle prestazioni senza introdurre latenza in-path.

9. Operatività pronta per gli incidenti

   • Creare allarmi per picchi di negazioni (deny) in Cloud Armor, nei log delle regole firewall o per modifiche alle policy gerarchiche. Documentare una procedura SSH di emergenza (break-glass) utilizzando gcloud compute ssh da Cloud Shell per un accesso di emergenza controllato.
   • Motivazione: Rileva rapidamente l’abuso attivo e preserva un percorso operativo sicuro per la remediation.

10. Sicurezza delle modifiche e rollback

    • Mettere in staging le modifiche di Cloud Armor in modalità di anteprima (preview), quindi applicarle. Per le modifiche al firewall, utilizzare priorità a basso rischio e progetti canary prima di propagarle alla policy a livello di organizzazione.
    • Motivazione: Minimizza la possibilità di interruzioni globali dovute a errori nelle policy, mantenendo al contempo una solida postura di sicurezza.

← Architettura VPC · Tutti i domini · Connettività ibrida →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →