Google PCNE: Firewall-Richtlinien, Cloud Armor und Netzwerksicherheit — Lernleitfaden

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

Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Firewall-Richtlinien, Cloud Armor und Netzwerksicherheit in Google Cloud bieten zusammen mehrschichtige Kontrollen für Segmentierung, Reduzierung der Angriffsfläche, DDoS-Resilienz und Beobachtbarkeit. Effektive Architekturen kombinieren identitätsbasierte Zielausrichtung, hierarchische Durchsetzung, Ingress und Egress nach dem Prinzip der geringsten Rechte sowie Schutzmaßnahmen am Netzwerkrand (Edge), die an die globalen Load Balancer von Google gekoppelt sind. Der operative Erfolg hängt vom Verständnis der Regelauswertung, impliziter Verhaltensweisen, des Protokollierungsumfangs und davon ab, woher der Traffic bei verschiedenen Load-Balancing-Modi tatsächlich stammt.

VPC-Firewallregeln und identitätsbasierte Zielausrichtung

VPC-Firewallregeln sind zustandsbehaftet (stateful) und werden pro Netzwerk, Richtung und Priorität ausgewertet.

Richtung und implizite Regeln:
- Ingress wird für Traffic ausgewertet, der in eine VM-NIC eintritt; Egress für Traffic, der sie verlässt.
- In jeder VPC existieren zwei implizite Regeln: eine implizite Regel, die jeglichen Ingress-Traffic verweigert (deny-all), und eine implizite Regel, die jeglichen Egress-Traffic erlaubt (allow-all). Diese können nicht geändert werden und erzeugen keine Protokolle. Das Standardnetzwerk erstellt zusätzlich mehrere freizügige Regeln; benutzerdefinierte VPCs tun dies nicht.
Priorität und Auswertung:
- Prioritäten reichen von 0 bis 65535, wobei niedrigere Werte zuerst ausgewertet werden. Die erste passende Regel bestimmt die Aktion vollständig.
- Wenn mehrere Regeln mit derselben Priorität übereinstimmen, gewinnt der spezifischste IP-Bereich. Bei gleicher Spezifität und widersprüchlichen Aktionen gewinnt die Ablehnung (Deny). Vermeiden Sie Überschneidungen bei gleicher Priorität.
Ziele und Quellen:
- Ziele (Targets) definieren, für welche VMs die Regel gilt: Netzwerk-Tags, VM-Dienstkonten oder sichere Tags. Quellen/Ziele sind IP-CIDRs; für Ingress können Sie auch Quell-Dienstkonten oder -Tags für Quellen innerhalb derselben VPC angeben.
- Netzwerk-Tags sind VM-Metadaten, die von Projektbenutzern festgelegt werden können; sie sind einfach, aber weniger kontrolliert. Dienstkonten ermöglichen eine identitätsbasierte Zielausrichtung, die an die Workload-Identität und IAM gebunden ist und schwerer zu missbrauchen ist. Sichere Tags (Tags des Ressourcen-Managers auf Organisationsebene, die über IAM gebunden sind) ermöglichen es Sicherheitsteams zu steuern, auf welche VMs eine Regel abzielen kann, ohne Entwicklern zu erlauben, sich selbst Tags zuzuweisen, die Schutzmaßnahmen umgehen; verwenden Sie sie für eine stärkere Governance.
Protokollierung:
- Aktivieren Sie das Firewall-Regel-Logging pro Regel, um erlaubte oder abgelehnte Verbindungen zu erfassen, die von dieser Regel erfasst wurden. Implizite Ablehnungen werden nicht protokolliert; wenn Sie Deny-Protokolle benötigen, fügen Sie eine explizite Ablehnungsregel mit hoher Priorität und aktivierter Protokollierung hinzu.
- Protokolle enthalten Regelreferenz, Aktion, 5-Tupel, Bytes und können für die Forensik exportiert werden.

Design und Betrieb:

Ingress nach dem Prinzip der geringsten Rechte: Bevorzugen Sie ein „Deny-by-Default“-Modell durch explizite Ablehnungsregeln mit hoher Priorität und fügen Sie dann bereichsbezogene Erlaubnisregeln (Allows) nach Dienstkonto oder sicherem Tag hinzu. Erlauben Sie für Instanzgruppen hinter einem Load Balancer nur Traffic vom Load Balancer oder den Systemdiagnosebereichen, die den Traffic tatsächlich verursachen.
Egress nach dem Prinzip der geringsten Rechte: Ersetzen Sie die implizite Erlaubnisregel durch eine explizite „Deny-All“-Egress-Regel mit hoher Priorität sowie gezielte Erlaubnisregeln (z. B. für NAT-Bereiche, Partner-IPs oder Google APIs über Private Google Access). Achten Sie darauf, keine Rückflüsse zu unterbrechen; die Zustandsbehaftung (Statefulness) erlaubt Antworten auf zugelassene Verbindungen ohne zusätzliche Regeln.
Identitätsbasierte Zielausrichtung:
- Verwenden Sie Dienstkonten für Richtlinien, die festlegen, „wer mit wem kommunizieren darf“, unabhängig von der IP-Mobilität.
- Verwenden Sie sichere Tags, um zu verhindern, dass Entwickler sich selbst freizügige Netzwerk-Tags zuweisen.
Häufige Fallstricke und Fehlermodi:
- Quellidentität des Load Balancers: Bei externen HTTP(S)-Load-Balancern sehen die Backends Verbindungen von Google Front End (GFE)-Proxys, nicht von den Client-IPs. Verwenden Sie Cloud Armor, um Client-IPs zuzulassen/abzulehnen; verwenden Sie die VPC-Firewall, um GFE-Egress- und Systemdiagnosebereiche zuzulassen. Bei TCP/UDP-Netzwerk-Load-Balancern sehen die Backends die Client-IP; Firewall-Allowlists für Client-IPs gelten direkt.
- Fehlende Deny-Protokolle: Ablehnungen durch implizite Regeln werden nicht protokolliert. Fügen Sie eine explizite Ablehnungsregel mit aktivierter Protokollierung hinzu, um blockierten Traffic zu beobachten.
- NAT-Umgehung: Wenn eine VM eine externe IP-Adresse hat, wird sie diese für den Egress-Traffic verwenden und Cloud NAT umgehen. Entfernen Sie die externe IP, um die Nutzung von NAT zu erzwingen.
- Diagnose von nicht passenden Regeln: Überprüfen Sie Richtung, Zielidentität (Tag/Dienstkonto/sicheres Tag), Priorität und Quellfilter. Wenn die Protokolle keine Übereinstimmung zeigen, trifft der Traffic nicht auf die erwartete Regel.

Kurzes Beispiel, identitätsbasierte Ingress-Erlaubnisregel mit Protokollierung:

Ziel: Dienstkonto sa: web-backend@project.iam.gserviceaccount.com
Quellbereiche: GFE-Proxy-Bereiche + Google-Systemdiagnosen
Priorität: 100
Aktion: allow tcp:80,443
Protokollierung: an

Hierarchische Firewall-Richtlinien, Segmentierung und Service-Perimeter

Hierarchische Firewall-Richtlinien setzen organisations- oder ordnerweite Regeln durch, bevor Regeln auf VPC-Ebene greifen. Verwenden Sie sie, um Leitplanken (Guardrails) zu garantieren (z. B. „jeglichen Ingress-Traffic aus dem Internet zu VMs ohne Load Balancer verweigern“ oder „RDP/SSH von 0.0.0.0/0 verweigern“). Regeln auf niedrigerer VPC-Ebene können eine bereits zutreffende Verweigerungsregel auf Organisations-/Ordnerebene nicht überschreiben.

Segmentierungsstrategie:

Ingress-Segmentierung:
- Organisations-/Ordnerrichtlinie: Verweigerungsregeln mit hoher Priorität für riskante Ports und eine standardmäßige Verweigerung mit Ausnahme von genehmigten Eingangspunkten. Erlauben Sie bei Bedarf die IP-Bereiche der Google-Systemdiagnosen (Health Checks).
- VPC-Regeln: Workload-spezifische Erlaubnisregeln, die auf ein Servicekonto oder ein sicheres Tag (Secure Tag) abzielen. Für interne Dienste verwenden Sie Private Service Connect oder internes Load Balancing für den Ost-West-Zugriff mit eingeschränkten Regeln.
Egress-Segmentierung:
- Ersetzen Sie die implizite Regel, die allen Egress-Traffic erlaubt, durch eine Regel mit hoher Priorität, die allen Egress-Traffic auf Organisations-/Ordner- oder VPC-Ebene verweigert, und öffnen Sie dann nur das, was benötigt wird:
  - Internet-Egress über Cloud NAT oder genehmigte Egress-Firewalls.
  - Google APIs über Private Google Access und die Endpunkte private.googleapis.com oder restricted.googleapis.com. Der eingeschränkte Endpunkt (restricted) wird mit VPC Service Controls kombiniert, um Daten-Exfiltration zu nicht autorisierten Identitäten oder Projekten zu verhindern.
  - Für Architekturen, die 0.0.0.0/0 durch eine Drittanbieter-Firewall leiten, aber dennoch direkten Zugriff auf Google APIs ohne Hairpinning erfordern, fügen Sie statische Routen für die VIP-Blöcke der Google APIs zum Standard-Internet-Gateway hinzu und aktivieren Sie Private Google Access in den Subnetzen. Dies erhält die Sicherheitskontrollen bei, während Latenz und Abhängigkeit vom Drittanbietergerät für Erstanbieterdienste reduziert werden.

Interaktionen mit Service-Perimetern:

VPC Service Controls definieren Perimeter um Projekte und unterstützte Google APIs, um Daten-Exfiltration zu verhindern. Wenn Perimeter aktiviert sind:
- Bevorzugen Sie restricted.googleapis.com, damit API-Aufrufe innerhalb des Perimeter-Kontexts bleiben müssen.
- Stellen Sie sicher, dass DNS die relevanten Domains auf die eingeschränkten (restricted) oder privaten (private) Endpunkte verweist und dass Routen den Traffic nicht zurück zu nicht vertrauenswürdigen Egress-Geräten leiten (Backhauling).
- Kombinieren Sie die Perimeter-Richtlinie mit Allow-Listen der Egress-Firewall, um versehentliche Lecks zu Endpunkten außerhalb des Perimeters zu vermeiden.

Abwägungen:

Verweigerungsregeln auf Organisationsebene vereinfachen das Risikomanagement, können aber legitime Experimente blockieren, wenn die Änderungssteuerung (Change Control) langsam ist; delegieren Sie Ausnahmen mithilfe von sicheren Tags (Secure Tags) und dokumentierten Anfrage-Workflows.
Aggressive Egress-Verweigerungsregeln reduzieren den potenziellen Schaden (Blast Radius), erfordern aber eine robuste Service Discovery und Änderungssteuerung, um Ausfälle zu verhindern.

Cloud Armor, WAF und globaler Edge-Schutz

Cloud Armor bindet Sicherheitsrichtlinien an externe HTTP(S)- und externe TCP/SSL-Proxy-Load-Balancer, um Schutz am Edge zu bieten.

WAF-Regeln:
- Verwenden Sie vorkonfigurierte Regeln für die OWASP Top 10 und gängige CVEs sowie benutzerdefinierte Regeln, die eine Ausdruckssprache verwenden, um Übereinstimmungen für Header, IPs, Länder, URIs und mehr zu finden.
- Weisen Sie die Regeln pro Backend-Dienst zu und ordnen Sie sie nach Priorität. Zu den Aktionen gehören Erlauben, Verweigern mit spezifischen Antworten oder Umleiten für HTTP(S).
Ratenbegrenzung:
- Setzen Sie Kontingente pro Schlüssel (z. B. nach Client-IP, Header oder Cookie) mit gleitenden Zeitfenstern (Sliding Windows) und Burst-Steuerung durch. Ratenbasierte Sperren fügen automatisch temporäre Verweigerungsregeln für missbräuchliche Quellen hinzu.
Adaptive Protection:
- ML-gestützte Anomalieerkennung lernt normale Anfrage-Muster und deckt L7-DDoS oder Missbrauch auf. Sie kann Regelkandidaten vorschlagen oder automatisch generieren; stellen Sie diese zuerst im Vorschaumodus (Preview) bereit.
Vorschaumodus (Preview):
- Evaluieren Sie neue Regeln, ohne den Traffic zu beeinträchtigen. Die Ergebnisse der Vorschau werden protokolliert, was eine risikoarme Feinabstimmung ermöglicht. Wechseln Sie nach der Überprüfung in den erzwungenen Modus (Enforced Mode).

DDoS-Abwehr und Steuerelemente für globale Load Balancer:

Googles globaler Anycast-Edge absorbiert volumetrische L3/L4-Angriffe; SYN/ACK-Validierung, die Handhabung fehlerhafter Pakete und die automatische Skalierung der Edge-Kapazität sind für externe HTTP(S)- und TCP/SSL-Proxy-Load-Balancer in die Plattform integriert.
Kombinieren Sie dies mit Cloud Armor, um L7-Floods, Credential Stuffing und Anwendungsmissbrauch zu mitigieren.
Setzen Sie TLS-Richtlinien, moderne Ciphers und bei Bedarf clientseitiges mTLS am Load Balancer durch. Für IPv6-Anforderungen verwenden Sie einen globalen externen HTTP(S)- oder TCP/SSL-Proxy-Load-Balancer mit IPv6-VIPs.
Für das Hinzufügen spezifischer Client-IPs zu einer Allow-Liste für eine Anwendung mit Load Balancer:
- Wenn Sie HTTP(S) verwenden, bevorzugen Sie Cloud Armor Allow-Listen, die auf der Client-IP basieren, und beschränken Sie die Backend-Firewall-Regeln auf die Quellen von GFE und Systemdiagnosen (Health Checks).
- Wenn Sie einen TCP/UDP-Netzwerk-Load-Balancer verwenden, sehen die Backends die echte Client-IP; wenden Sie VPC-Firewall-Allow-Listen direkt auf die Zielinstanzen an (über ein sicheres Tag oder ein Servicekonto) und schließen Sie die IPs der Google-Systemdiagnosen (Health Checks) mit ein.

Betriebliche Hinweise:

Regeln werden am Edge ausgewertet; falsche Allow-Listen können sofort zu globalen Ausfällen führen. Nutzen Sie den Vorschaumodus und gestaffelte Rollouts (Staged Rollouts) und überwachen Sie die Cloud Armor-Logs und die Metriken des Load Balancers.
Die Anforderungen an die Sitzungsaffinität variieren: Bei gemischten Protokollen (z. B. HTTP und TFTP vom selben Client zum selben Backend-Pool) erhält die Client-IP-Affinität am Load Balancer die Sitzungsbindung (Stickiness) über verschiedene Ports hinweg.

Sichtbarkeit, Überprüfung und Reaktion auf Vorfälle

Beobachtbarkeit:

VPC Flow Logs liefern gesampelte 5-Tupel-Flow-Datensätze pro Subnetz mit konfigurierbarem Sampling, Metadatenanreicherung und Aggregationsintervallen. Verwenden Sie sie für Performance-Baselining und Anomalieerkennung.
Die Protokollierung von Firewall-Regeln erfasst Zulassungen und Ablehnungen pro Verbindung für die spezifischen Regeln, bei denen die Protokollierung aktiviert ist. Erstellen Sie explizite Ablehnungsregeln, um Blockierungen zu protokollieren, die andernfalls auf implizite Ablehnungen treffen würden.
Cloud Armor-Anforderungsprotokolle und Vorschauergebnisse zeigen Regelübereinstimmungen, Aktionsentscheidungen und Ergebnisse der Ratenbegrenzung am Edge.

Überprüfung und Erkennung:

Packet Mirroring kopiert den Datenverkehr zu einem Collector in derselben Region für Deep Packet Inspection oder IDS. Beschränken Sie die Spiegelung nach Subnetz, Tag oder Service-Account, um den Overhead zu begrenzen. Packet Mirroring ist out-of-band und blockiert nicht; verwenden Sie es mit Cloud IDS oder Sensoren von Drittanbietern.
Die Inline-L7-Inspektion erfordert ein 2-NIC-Appliance-Muster und das Routing durch dieses. Sorgen Sie für symmetrisches Routing und Hochverfügbarkeit (HA); berücksichtigen Sie regionale Fehlerdomänen und potenzielle Durchsatzengpässe. Inline-Geräte vergrößern den „Blast Radius“ (Schadensradius), wenn sie ausfallen; setzen Sie gegebenenfalls verwaltete Instanzgruppen und durch Systemdiagnosen geprüfte Routen-Failover-Muster ein.

Praktiken für die Reaktion auf Vorfälle:

Zentralisieren Sie Logs in einem Sicherheitsprojekt, erstellen Sie Erkennungen für plötzliche Anstiege bei Ablehnungen, die Erstellung neuer Regeln mit hoher Priorität oder Auslöser von Cloud Armor-Ratenbegrenzungen. Nutzen Sie BigQuery oder SIEM-Integrationen für die Untersuchung.
Stellen Sie IAM mit den geringsten Rechten sicher: Der Network Admin ist nicht ausreichend, um Firewall-Richtlinien in einer Shared VPC zu ändern, wo der Security Admin erforderlich ist; trennen Sie die Aufgaben zwischen Netzwerk- und Sicherheitsteams.
Wenn Sie einen Break-Glass-SSH-Zugriff benötigen und keine Schlüssel vorab bereitgestellt sind, verwenden Sie

undefined

von Cloud Shell, um einen ephemeren Schlüssel über die Instanz-Metadaten zu pushen, sofern dies durch IAM und die Einstellungen der Instanz-Metadaten erlaubt ist.

Zur Fehlerbehebung bei „Keine Logs“-Szenarien: Überprüfen Sie die Regel und die Richtung, denken Sie daran, dass implizite Ablehnungen nicht protokollieren, und prüfen Sie hierarchische Richtlinien, die möglicherweise früher gegriffen haben.

Praktisches Problemszenario

Contoso Retail betreibt eine mehrstufige Webplattform auf Google Cloud. Der Frontend-Traffic wird von einem globalen externen HTTP(S)-Load-Balancer bedient; Anwendungs-VMs laufen in mehreren Regionen ohne externe IPs. Ausgehender Verkehr (Egress) muss über eine NGFW eines Drittanbieters per Hairpinning geleitet werden, außer für Google APIs (BigQuery und Pub/Sub). Das Sicherheitsteam wünscht sich organisationsweite Guardrails, Client-IP-Allow-Listen für ein Partner-Pilotprojekt und ein minimales Risiko beim Testen eines mutmaßlich bösartigen Clients.

Vorgehensweise:

Hierarchische Guardrails einrichten
- Erstellen Sie eine hierarchische Firewall-Richtlinie auf Organisationsebene, die den gesamten eingehenden Verkehr von 0.0.0.0/0 zu VM-Zielen ohne das sichere Tag

undefined

verweigert und administrative Ports (SSH, RDP) aus dem Internet blockiert.

Begründung: Stoppt unsichere Exposition global; Entwickler können sich das sichere Tag aufgrund von IAM für Tags nicht selbst zuweisen.

Identitätsbewusstes Workload-Targeting
- Weisen Sie den Frontend-, Anwendungs- und Datenbank-Tiers unterschiedliche Service-Accounts zu. Referenzieren Sie diese Service-Accounts in Firewall-Regeln auf VPC-Ebene, um nur die erforderlichen Ost-West-Verkehrsflüsse zu erlauben (z. B. Frontend→App

undefined

, App→DB

undefined

Begründung: Verknüpft die Richtlinie mit der Workload-Identität und verhindert versehentlichen Missbrauch von Tags.

Ingress-Zulassungen für Load-Balancer-Backends
- Erstellen Sie auf den App-VMs eine Ingress-Zulassungsregel mit hoher Priorität, die auf den App-Service-Account abzielt, mit Quellbereichen, die den Google Front End-Proxys und den Google Health Check-Bereichen entsprechen; aktivieren Sie die Protokollierung.
- Begründung: Bei HTTP(S) L7 sollten Backends nur Verbindungen von GFE- und Health-Check-IPs akzeptieren; Allow-Listen für Client-IPs werden am Edge durchgesetzt.
Cloud Armor Edge-Richtlinie
- Hängen Sie eine Cloud Armor-Richtlinie an den Backend-Dienst des externen HTTP(S)-Load-Balancers an:
  - Fügen Sie eine Regel für die Partner-Client-IP-Allow-Liste hinzu.
  - Aktivieren Sie vorkonfigurierte WAF-Regeln für die OWASP Top 10.
  - Konfigurieren Sie eine Ratenbegrenzung basierend auf der Client-IP mit konservativen Schwellenwerten.
- Begründung: Setzt Quellbeschränkungen für Clients und Schutzmechanismen auf Anwendungsebene dort durch, wo die Client-IP sichtbar ist und bevor der Verkehr die VPC erreicht.
Adaptiver Schutz und sicheres Testen
- Aktivieren Sie Adaptive Protection und erstellen Sie eine Ablehnungsregel für die verdächtige Client-IP im Vorschaumodus.
- Begründung: Die Vorschau ermöglicht die Überprüfung des Verhaltens, ohne echte Benutzer zu beeinträchtigen; Protokolle bestätigen, ob der Client bösartig ist, bevor die Regel durchgesetzt wird.
Egress-Segmentierung mit Private Google Access
- Behalten Sie eine 0.0.0.0/0-Route zur NGFW des Drittanbieters bei. Fügen Sie benutzerdefinierte statische Routen für die VIPs der Google APIs zum Standard-Internet-Gateway hinzu und aktivieren Sie Private Google Access auf den Subnetzen. Fügen Sie eine explizite Egress-Deny-All-Regel mit hoher Priorität hinzu, dann spezifische Zulassungen für den NGFW-Next-Hop und die Google APIs; aktivieren Sie die Protokollierung.
- Begründung: Zwingt den allgemeinen Internet-Egress durch die NGFW, während BigQuery und Pub/Sub privat ohne unnötiges Hairpinning erreicht werden können.
NAT- und externe IP-Kontrollen
- Verwenden Sie Cloud NAT für Instanzen, die Internet-Egress benötigen, aber keine externen IPs haben. Überprüfen und entfernen Sie alle externen IPs auf Compute-Instanzen, die NAT verwenden müssen.
- Begründung: Verhindert die Umgehung von NAT und bewahrt eine einheitliche Egress-Haltung.
Überprüfung und Überwachung
- Aktivieren Sie Packet Mirroring in jeder Region für den App-Tier, zielen Sie auf den App-Service-Account und senden Sie den gespiegelten Verkehr an einen regionalen IDS-Collector. Aktivieren Sie VPC Flow Logs und die Protokollierung von Firewall-Regeln für Schlüsselregeln; exportieren Sie Cloud Armor- und VPC-Logs in ein zentrales Sicherheitsprojekt und nach BigQuery.
- Begründung: Bietet tiefe Einblicke für die Bedrohungssuche (Threat Hunting) und Performance-Baselines ohne Latenz im Datenpfad.
Vorfallsbereite Betriebsabläufe
- Erstellen Sie Benachrichtigungen bei Spitzen in Cloud Armor-Ablehnungen, Firewall-Ablehnungsprotokollen oder Änderungen an hierarchischen Richtlinien. Dokumentieren Sie ein Break-Glass-SSH-Verfahren mit

undefined

für kontrollierten Notfallzugriff.

Begründung: Erkennt aktiven Missbrauch schnell und erhält einen sicheren operativen Pfad zur Behebung.

Änderungssicherheit und Rollback

Stagen Sie Cloud Armor-Änderungen in der Vorschau und setzen Sie sie dann durch. Verwenden Sie für Firewall-Änderungen Prioritäten mit geringerem Risiko und Canary-Projekte, bevor Sie sie auf die Richtlinie auf Organisationsebene ausweiten.
Begründung: Minimiert das Risiko globaler Ausfälle durch Richtlinienfehler bei gleichzeitiger Aufrechterhaltung einer starken Sicherheitsarchitektur.

← VPC-Architektur · Alle Domänen · Hybride Konnektivität →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →