Google PCNE: Firewallbeleid, Cloud Armor en Netwerkbeveiliging — Studiegids

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

Onderdeel van de Google Professional Cloud Network Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Firewall-beleid, Cloud Armor en netwerkbeveiliging op Google Cloud bieden samen gelaagde controles voor segmentatie, verkleining van het aanvalsoppervlak, DDoS-bestendigheid en observeerbaarheid. Effectieve ontwerpen combineren identiteitsbewuste targeting, hiërarchische handhaving, minimale rechten voor inkomend en uitgaand verkeer (least-privilege ingress en egress), en edge-bescherming gekoppeld aan de wereldwijde load balancers van Google. Operationeel succes hangt af van het begrijpen van de regelevaluatie, impliciet gedrag, de reikwijdte van logging en waar het verkeer daadwerkelijk vandaan komt voor verschillende load-balancing-modi.

VPC-firewallregels en identiteitsbewuste targeting

VPC-firewallregels zijn stateful en worden geëvalueerd per netwerk, richting en prioriteit.

Richting en impliciete regels:
- Ingress wordt geëvalueerd voor verkeer dat een VM NIC binnenkomt; egress voor verkeer dat deze verlaat.
- In elke VPC bestaan twee impliciete regels: een impliciete ‘deny-all’ voor ingress en een impliciete ‘allow-all’ voor egress. Deze kunnen niet worden gewijzigd en produceren geen logs. Het standaardnetwerk maakt ook verschillende permissieve regels aan; aangepaste VPC’s doen dat niet.
Prioriteit en evaluatie:
- Prioriteiten lopen van 0 tot 65535, waarbij een lager getal als eerste wordt geëvalueerd. De eerste overeenkomende regel bepaalt de actie volledig.
- Als meerdere regels met dezelfde prioriteit overeenkomen, wint het meest specifieke IP-bereik; bij gelijke specificiteit en tegenstrijdige acties, wint ‘deny’. Vermijd overlappingen met dezelfde prioriteit.
Targets en sources:
- Targets definiëren op welke VM’s de regel van toepassing is: netwerktags, VM-serviceaccounts of secure tags. Sources/destinations zijn IP CIDR’s; voor ingress kun je ook source-serviceaccounts of -tags specificeren voor bronnen binnen dezelfde VPC.
- Netwerktags zijn VM-metadata die door projectgebruikers kunnen worden ingesteld; ze zijn eenvoudig maar minder gecontroleerd. Serviceaccounts bieden identiteitsbewuste targeting gekoppeld aan workload-identiteit en IAM, wat misbruik moeilijker maakt. Secure tags (resource manager-tags op organisatieniveau, gekoppeld via IAM) stellen beveiligingsteams in staat te bepalen op welke VM’s een regel gericht kan zijn, zonder dat ontwikkelaars zelf tags kunnen toewijzen die de beveiliging omzeilen; gebruik ze voor een sterkere governance.
Logging:
- Activeer firewallregellogging per regel om toegestane of geweigerde verbindingen vast te leggen die door die regel worden gematcht. Impliciete ‘denies’ worden niet gelogd; als je ‘deny’-logs nodig hebt, voeg dan een expliciete ‘deny’-regel met hoge prioriteit en ingeschakelde logging toe.
- Logs bevatten een regelreferentie, actie, 5-tuple, bytes en kunnen worden geëxporteerd voor forensisch onderzoek.

Ontwerp en operaties:

Least-privilege ingress: Geef de voorkeur aan ‘deny-by-default’ met expliciete ‘deny’-regels met hoge prioriteit, en voeg vervolgens beperkte ‘allow’-regels toe per serviceaccount of secure tag. Voor instance groups achter een load balancer, sta alleen verkeer toe vanaf de load balancer of de health check-bereiken die het verkeer daadwerkelijk initiëren.
Least-privilege egress: Vervang de impliciete ‘allow’ door een expliciete ‘deny-all’ egress-regel met hoge prioriteit, plus gerichte ‘allow’-regels (voor NAT-bereiken, IP’s van partners, of Google API’s via Private Google Access). Wees voorzichtig dat je de retourstromen niet verbreekt; statefulness staat antwoorden op toegestane verbindingen toe zonder extra regels.
Identiteitsbewuste targeting:
- Gebruik serviceaccounts voor ‘wie-mag-praten’-beleid, onafhankelijk van IP-mobiliteit.
- Gebruik secure tags om te voorkomen dat ontwikkelaars zelf permissieve netwerktags toepassen.
Veelvoorkomende valkuilen en faalmodi:
- Bronidentiteit van de load balancer: Bij externe HTTP(S) load balancers zien backends verbindingen van Google Front End-proxy’s, niet van de IP’s van de client. Gebruik Cloud Armor voor ‘allow/deny’ op basis van client-IP; gebruik de VPC-firewall om GFE-egress en health check-bereiken toe te staan. Bij TCP/UDP Network Load Balancers zien backends het IP-adres van de client; firewall-whitelists van client-IP’s zijn direct van toepassing.
- Ontbrekende ‘deny’-logs: ‘Denies’ van impliciete regels worden niet gelogd. Voeg een expliciete ‘deny’-regel met ingeschakelde logging toe om geblokkeerd verkeer te observeren.
- NAT-bypass: Als een VM een extern IP-adres heeft, zal deze dat gebruiken voor egress en Cloud NAT omzeilen. Verwijder het externe IP-adres om het gebruik van NAT af te dwingen.
- Diagnose van regelmismatch: Controleer de richting, target-identiteit (tag/serviceaccount/secure tag), prioriteit en bronfilters. Als de logs geen match tonen, bereikt het verkeer niet de regel die je verwacht.

Kort voorbeeld, identiteitsbewuste ingress ‘allow’ met logging:

Target: serviceaccount sa: web-backend@project.iam.gserviceaccount.com
Source-bereiken: GFE-proxybereiken + Google health checks
Prioriteit: 100
Actie: allow tcp:80,443
Logging: on

Hiërarchisch firewallbeleid, segmentatie en serviceperimeters

Hiërarchische firewallbeleidsregels dwingen regels af op organisatie- of mapniveau voordat regels op VPC-niveau worden toegepast. Gebruik ze om guardrails te garanderen (bijvoorbeeld “alle ingress vanaf het internet naar niet-load-balanced VM’s weigeren” of “RDP/SSH vanaf 0.0.0.0/0 weigeren”). VPC-regels op een lager niveau kunnen een ‘deny’ op organisatie-/mapniveau die al is gematcht niet overschrijven.

Segmentatiestrategie:

Ingress-segmentatie:
- Beleid op organisatie-/mapniveau: ‘denies’ met hoge prioriteit voor risicovolle poorten en een standaard ‘deny’, behalve voor goedgekeurde toegangspunten. Sta de Google health check-ranges toe waar nodig.
- VPC-regels: workload-specifieke ‘allows’ gericht op service account of secure tag. Gebruik voor interne services Private Service Connect of interne load balancing voor oost-west-toegang met beperkte regels.
Egress-segmentatie:
- Vervang de impliciete ‘allow-all’ egress door een ‘deny-all’ egress met hoge prioriteit op organisatie-/map- of VPC-niveau, en open vervolgens alleen wat nodig is:
  - Internet-egress via Cloud NAT of goedgekeurde egress-firewalls.
  - Google API’s via Private Google Access en private.googleapis.com- of restricted.googleapis.com-eindpunten. Het restricted endpoint werkt samen met VPC Service Controls om data-exfiltratie naar ongeautoriseerde identiteiten of projecten te voorkomen.
  - Voor ontwerpen die 0.0.0.0/0 via een firewall van derden sturen, maar toch directe toegang tot Google API’s vereisen zonder hairpinning: voeg statische routes voor de Google API’s VIP-blokken toe aan de standaard internetgateway en schakel Private Google Access in op de subnetten. Dit behoudt de beveiligingsmaatregelen en vermindert tegelijkertijd de latency en afhankelijkheid van het apparaat van derden voor first-party services.

Interacties met serviceperimeters:

VPC Service Controls definiëren perimeters rond projecten en ondersteunde Google API’s om data-exfiltratie te beperken. Wanneer perimeters zijn ingeschakeld:
- Geef de voorkeur aan restricted.googleapis.com zodat API-aanroepen binnen de perimetercontext moeten blijven.
- Zorg ervoor dat DNS de relevante domeinen naar de restricted of private eindpunten verwijst en dat routes niet teruglopen naar niet-vertrouwde egress-apparaten.
- Combineer perimeterbeleid met allowlists van de egress-firewall om onbedoelde lekken naar eindpunten buiten de perimeter te voorkomen.

Afwegingen:

‘Denies’ op organisatieniveau vereenvoudigen risicobeheer, maar kunnen legitieme experimenten blokkeren als change control traag is; delegeer uitzonderingen met behulp van secure tags en gedocumenteerde aanvraagworkflows.
Agressieve egress ‘denies’ verkleinen de ‘blast radius’, maar vereisen robuuste service discovery en change control om storingen te voorkomen.

Cloud Armor, WAF en wereldwijde edge-beveiliging

Cloud Armor koppelt beveiligingsbeleid aan externe HTTP(S) en externe TCP/SSL Proxy load balancers om beveiliging aan de edge te bieden.

WAF-regels:
- Gebruik voorgeconfigureerde regels voor OWASP Top 10 en veelvoorkomende CVE’s, en aangepaste regels met behulp van een expressietaal om te matchen op headers, IP’s, landen, URI’s en meer.
- Koppel per backend service en orden regels op prioriteit. Acties zijn onder meer ‘allow’, ‘deny’ met specifieke responses, of ‘redirect’ voor HTTP(S).
Rate limiting:
- Dwing quota per sleutel af (bijvoorbeeld per client-IP, header of cookie) met ‘sliding windows’ en ‘burst controls’. Op rate gebaseerde bans voegen automatisch tijdelijke ‘denies’ toe voor misbruikende bronnen.
Adaptive Protection:
- ML-gestuurde anomaliedetectie leert normale aanvraagpatronen en detecteert L7 DDoS of misbruik. Het kan kandidaatregels voorstellen of automatisch genereren; implementeer deze eerst in preview-modus.
Preview-modus:
- Evalueer nieuwe regels zonder het verkeer te beïnvloeden. Resultaten van de preview worden gelogd, wat tuning met een laag risico mogelijk maakt. Schakel na verificatie over naar de ’enforced’ modus.

DDoS-verdediging en besturingselementen voor globale load balancers:

Google’s wereldwijde anycast edge absorbeert volumetrische L3/L4-aanvallen; SYN/ACK-validatie, verwerking van misvormde pakketten en het automatisch schalen van edge-capaciteit zijn ingebouwd in het platform voor externe HTTP(S) en TCP/SSL Proxy.
Combineer met Cloud Armor om L7-floods, credential stuffing en applicatiemisbruik te beperken.
Dwing TLS-beleid, moderne ciphers en, waar nodig, client mTLS af op de load balancer. Gebruik voor IPv6-vereisten een globale externe HTTP(S) of TCP/SSL Proxy load balancer met IPv6 VIP’s.
Voor het op een allowlist plaatsen van specifieke client-IP’s voor een load-balanced app:
- Als u HTTP(S) gebruikt, geef dan de voorkeur aan Cloud Armor-allowlists op basis van client-IP en beperk de firewallregels van de backend tot GFE- en health check-bronnen.
- Als u een TCP/UDP Network Load Balancer gebruikt, zien de backends het echte client-IP; pas VPC-firewall-allowlists rechtstreeks toe op de doel-instances (via secure tag of service account) en neem de Google health check-IP’s op.

Operationele aandachtspunten:

Regels worden aan de edge geëvalueerd; onjuiste allowlists kunnen onmiddellijk wereldwijde storingen veroorzaken. Gebruik preview en gefaseerde rollouts, en monitor Cloud Armor-logs en load balancer-metrics.
De behoeften voor sessieaffiniteit variëren: voor gemengde protocollen (bijvoorbeeld HTTP en TFTP van dezelfde client naar dezelfde backend pool) behoudt client-IP-affiniteit op de load balancer de ‘stickiness’ over verschillende poorten.

Zichtbaarheid, inspectie en incidentrespons

Observeerbaarheid:

VPC Flow Logs leveren gesamplede 5-tuple flow-records per subnet met configureerbare sampling, metadataverrijking en aggregatie-intervallen. Gebruik ze voor het vaststellen van prestatiebaselines en voor anomaliedetectie.
Logging van firewallregels legt per verbinding de ‘allows’ en ‘denies’ vast voor de specifieke regels waarvoor logging is ingeschakeld; maak expliciete ‘deny’-regels om blokkades te loggen die anders door impliciete ‘denies’ zouden worden afgehandeld.
Cloud Armor-requestlogs en preview-resultaten tonen regelmatches, actiebeslissingen en de uitkomsten van rate-limiting aan de edge.

Inspectie en detectie:

Packet Mirroring kopieert verkeer naar een collector in dezelfde regio voor deep packet inspection of IDS. Beperk de mirroring op basis van subnet, tag of serviceaccount om overhead te minimaliseren. Packet Mirroring is out-of-band en blokkeert geen verkeer; gebruik het met Cloud IDS of sensoren van derden.
Inline L7-inspectie vereist een 2-NIC appliance-patroon en routering via deze appliance. Ontwerp voor symmetrische routering en HA; houd rekening met regionale ‘fault domains’ en mogelijke doorvoerknelpunten. Inline-apparaten vergroten de ‘blast radius’ als ze falen; implementeer waar van toepassing ‘managed instance groups’ en failover-patronen voor routes met health checks.

Praktijken voor incidentrespons:

Centraliseer logs in een security-project, bouw detecties voor plotselinge pieken in ‘denies’, het aanmaken van nieuwe regels met hoge prioriteit, of triggers van Cloud Armor rate limits. Gebruik BigQuery of SIEM-integraties voor onderzoek.
Zorg voor least-privilege IAM: Network Admin is onvoldoende om firewall-beleid in Shared VPC aan te passen, waarvoor Security Admin vereist is; scheid de taken tussen netwerk- en securityteams.
Wanneer je ‘break-glass’ SSH-toegang nodig hebt en sleutels niet vooraf zijn ingesteld, gebruik dan gcloud compute ssh vanuit Cloud Shell om een efemere sleutel via de instance-metadata te pushen, indien toegestaan door IAM en de instance-metadata-instellingen.
Voor het troubleshooten van ‘geen logs’-scenario’s: verifieer de regel en de richting, onthoud dat impliciete ‘denies’ niet loggen, en controleer hiërarchisch beleid dat mogelijk eerder een match heeft gevonden.

Praktisch Probleemscenario

Contoso Retail beheert een multi-tier webplatform op Google Cloud. Frontend-verkeer wordt afgehandeld door een global external HTTP(S) load balancer; applicatie-VM’s draaien in meerdere regio’s zonder externe IP’s. Egress-verkeer moet via een ‘hairpin’-route door een NGFW van een derde partij, behalve voor Google API’s (BigQuery en Pub/Sub). Het securityteam wil organisatiebrede ‘guardrails’, IP-allowlists voor een partnerpilot, en minimaal risico bij het testen van een verdachte kwaadaardige client.

Aanpak:

Hiërarchische guardrails opzetten
- Maak een hiërarchisch firewall-beleid op organisatieniveau dat alle ingress van 0.0.0.0/0 weigert naar VM-targets die de beveiligingstag env=public-entry missen, en dat administratieve poorten (SSH, RDP) vanaf het internet weigert.
- Rationale: Stopt onveilige blootstelling wereldwijd; ontwikkelaars kunnen de beveiligingstag niet zelf toewijzen vanwege IAM op tags.
Identiteitsbewuste targeting van workloads
- Wijs afzonderlijke serviceaccounts toe aan de frontend-, applicatie- en databasetiers. Verwijs naar deze serviceaccounts in firewallregels op VPC-niveau om alleen de vereiste east-west-flows toe te staan (bijvoorbeeld, frontend→app tcp:443, app→db tcp:5432).
- Rationale: Koppelt beleid aan de workload-identiteit en is bestand tegen onbedoeld misbruik van tags.
Ingress-allows voor backends achter een load balancer
- Maak op de app-VM’s een ingress ‘allow’-regel met hoge prioriteit, getarget op het serviceaccount van de app, met bronbereiken die gelijk zijn aan de Google Front End-proxy’s en de Google health check-bereiken; schakel logging in.
- Rationale: Voor HTTP(S) L7 moeten backends alleen verbindingen accepteren van GFE- en health check-IP’s; IP-allowlists van clients worden aan de edge afgedwongen.
Cloud Armor-beleid aan de edge
- Koppel een Cloud Armor-beleid aan de backend service van de external HTTP(S) load balancer:
  - Voeg een regel toe voor de IP-allowlist van de partnerclient.
  - Schakel voorgeconfigureerde WAF-regels voor OWASP Top 10 in.
  - Configureer een rate limit op basis van client-IP met conservatieve drempelwaarden.
- Rationale: Dwingt bronbeperkingen voor clients en beveiliging op applicatielaag af waar het client-IP zichtbaar is en voordat het verkeer de VPC bereikt.
Adaptieve bescherming en veilig testen
- Schakel Adaptive Protection in en maak een ‘deny’-regel voor het verdachte client-IP in preview-modus.
- Rationale: Preview maakt verificatie van gedrag mogelijk zonder echte gebruikers te beïnvloeden; logs bevestigen of de client kwaadaardig is voordat de regel wordt afgedwongen.
Egress-segmentatie met Private Google Access
- Behoud een 0.0.0.0/0-route naar de NGFW van de derde partij. Voeg aangepaste statische routes toe voor de VIP’s van Google API’s naar de standaard internetgateway en schakel Private Google Access in op de subnets. Voeg een expliciete ’egress deny-all’-regel met hoge prioriteit toe, gevolgd door specifieke ‘allows’ voor de NGFW next-hop en Google API’s; schakel logging in.
- Rationale: Dwingt algemeen internetverkeer via de NGFW, terwijl BigQuery en Pub/Sub privé bereikbaar zijn zonder onnodige ‘hairpinning’.
NAT- en externe IP-controles
- Gebruik Cloud NAT voor instances die internet-egress nodig hebben maar geen externe IP’s hebben. Controleer en verwijder alle externe IP’s op compute instances die NAT moeten gebruiken.
- Rationale: Voorkomt het omzeilen van NAT en handhaaft een eenduidige egress-houding.
Inspectie en monitoring
- Schakel Packet Mirroring in elke regio in voor de app-tier, getarget op het serviceaccount van de app, en stuur gespiegeld verkeer naar een regionale IDS-collector. Schakel VPC Flow Logs en logging van firewallregels in voor belangrijke regels; exporteer Cloud Armor- en VPC-logs naar een centraal security-project en BigQuery.
- Rationale: Biedt diepgaand inzicht voor ’threat hunting’ en prestatiebaselines zonder in-path latency.
Incident-ready operaties
- Bouw alerting op voor pieken in Cloud Armor ‘denies’, firewall ‘deny’-logs, of wijzigingen in hiërarchisch beleid. Documenteer een ‘break-glass’ SSH-procedure met behulp van Cloud Shell gcloud compute ssh voor gecontroleerde noodtoegang.
- Rationale: Detecteert actief misbruik snel en behoudt een veilig operationeel pad voor herstel.
Veilige wijzigingen en rollback

Test Cloud Armor-wijzigingen eerst in preview-modus en dwing ze daarna af. Gebruik voor firewallwijzigingen prioriteiten met een lager risico en ‘canary’-projecten voordat je ze doorvoert naar het beleid op organisatieniveau.
Rationale: Minimaliseert de kans op wereldwijde storingen door beleidsfouten, terwijl een sterke beveiligingshouding behouden blijft.

← VPC Architectuur · Alle domeinen · Hybride Connectiviteit →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →