Lab 04 GCP Network Security

Network security is one of the most important layers of Google Cloud defense.

Even when IAM is configured correctly, weak network controls can expose workloads to unnecessary risk.

In this lab, you will assess a Google Cloud network from the perspective of a Cloud Security Engineer and determine whether workloads are appropriately segmented, exposed, and monitored.

Mission Goal: Review a Google Cloud network, identify insecure exposure and overly broad access, validate private connectivity, and document network security findings with practical remediation.

Mission Information

Difficulty: Intermediate
Estimated Time: 75–120 minutes
Primary Skill: Google Cloud Network Security Assessment
Platform: Google Cloud
Career Alignment: Cloud Security Engineer, Network Security Engineer, Cloud Security Consultant, SOC Analyst

What You Will Learn

By completing this lab, you will learn how to:

Review VPC architecture
Assess subnet design
Understand routes
Review firewall rules
Identify overly broad ingress access
Review outbound connectivity
Identify public IP exposure
Understand private workloads
Review Cloud NAT
Evaluate network segmentation
Review network logging
Identify common GCP network security risks
Document professional security findings

Why This Lab Matters

A secure network should answer several questions clearly:

Who can connect?
        ↓
To which resource?
        ↓
On which port?
        ↓
From where?
        ↓
Is that communication required?

If the answer is unclear, the network deserves further review.

A common cloud security problem is not that a firewall rule does not work.

It is that the firewall rule works too broadly.

Lab Scenario

You are working as a Google Cloud Security Engineer.

A new application environment is preparing to move into production.

The architecture includes:

One VPC
Multiple subnets
Compute resources
Internet-facing workloads
Private workloads
Firewall rules
Outbound internet access

Before production approval, you have been asked to perform a network security review.

Your objectives are to determine whether:

Public exposure is necessary
Firewall access follows least privilege
Private workloads remain private
Network communication is appropriately segmented
Logging provides sufficient visibility

Lab Architecture

Use a conceptual environment similar to:

Internet
   │
   ↓
External Application
   │
   ├── Public / Frontend Subnet
   │         ↓
   │      Web VM
   │
   └── Private / Backend Subnet
             ↓
         Backend VM
             ↓
          Database

Outbound traffic from private resources may follow:

Private VM
    ↓
Cloud NAT
    ↓
Internet

Prerequisites

Before starting, make sure you have:

An authorized Google Cloud lab project
Permission to view networking resources
Permission to create disposable networking resources if needed
Familiarity with VPC concepts
Basic understanding of CIDR ranges
Completed the IAM and logging labs or understand those concepts

Lab Safety

Use only a dedicated or authorized lab environment.

Do not:

Modify production firewall policies
Expose sensitive workloads publicly
Remove required enterprise routes
Change shared networking without authorization
Disrupt legitimate business connectivity

Any intentionally insecure configuration used in this lab should be temporary and removed during cleanup.

Part 1 — Open the VPC Network Area

In Google Cloud Console, navigate to:

VPC Network
    ↓
VPC Networks

Review the networks available in the project.

For each VPC, record:

Name
Subnets
Routing mode
Connected resources
Purpose

First Security Question

Ask:

Why does this VPC exist, and which workloads should be allowed to communicate through it?

Do not start with individual rules before understanding the architecture.

Part 2 — Inventory the Network

Build a small inventory.

Resource	Type	Purpose	Exposure	Review
app-vpc	VPC	Application network	Internal	Yes
frontend-subnet	Subnet	Web tier	Public-facing workloads	Yes
backend-subnet	Subnet	Application tier	Private	Yes

The objective is to understand the network before evaluating security.

Part 3 — Review Subnets

For each subnet, record:

Region
CIDR range
Workloads
Intended trust level
Public or private role

Example:

app-vpc

├── frontend-subnet
│   10.10.1.0/24
│
└── backend-subnet
    10.10.2.0/24

Security Perspective

Subnets themselves are not automatically security boundaries.

You must combine subnet architecture with controls such as:

Firewall policies
Workload identity
Application controls
Routing
Network policies

Do not assume:

Different Subnet
      =
Secure Segmentation

Part 4 — Understand Network Paths

Take one application and draw its required communication.

For example:

Internet
   ↓
HTTPS 443
   ↓
Web Tier
   ↓
Application Port
   ↓
Backend
   ↓
Database Port
   ↓
Database

Now ask:

Which of these paths are required?

Anything beyond the required paths may represent unnecessary attack surface.

Part 5 — Review Firewall Rules

Navigate to the firewall configuration for the VPC.

Inventory the relevant rules.

Record:

Rule name
Direction
Action
Priority
Source
Destination
Protocol
Port
Target

Firewall Review Table

Rule	Direction	Source	Port	Target	Assessment
allow-web	Ingress	Internet	443	Web tier	Expected
allow-admin	Ingress	Broad	22	Multiple VMs	Review
allow-all	Ingress	Any	All	All	High Risk

Part 6 — Review Ingress Rules

Ingress determines what can reach your workloads.

For every ingress rule ask:

Who is the source?
        ↓
Which protocol?
        ↓
Which port?
        ↓
Which destination?
        ↓
Is it required?

Broad Ingress Example

A risky pattern may look like:

Internet
0.0.0.0/0
     ↓
SSH / RDP / All Ports
     ↓
Cloud Workload

This creates unnecessary exposure.

Part 7 — Identify 0.0.0.0/0 Access

Search for firewall rules allowing:

0.0.0.0/0

Do not assume every such rule is automatically incorrect.

Public websites may legitimately accept internet traffic.

The real questions are:

Which port?
Which workload?
Which business requirement?

For example:

0.0.0.0/0 → TCP 443 → Public Web Frontend

may be expected.

But:

0.0.0.0/0 → TCP 22 → All VMs

deserves immediate review.

Part 8 — Review Administrative Ports

Pay special attention to ports associated with administration.

Examples may include:

SSH
RDP
Database administration
Management services

Ask:

Does administration need to be reachable directly from the public internet?

In many secure architectures, the answer should be no.

Part 9 — Review Firewall Targets

A rule can have an acceptable source and port but still apply too broadly.

For example:

Trusted Admin Network
        ↓
SSH
        ↓
Every VM

may still be broader than needed.

Prefer targeting only the workloads that actually require the access.

Part 10 — Review Egress

Network security is not only about incoming connections.

Review outbound communication.

Ask:

Where can the workload connect?
        ↓
Does it need unrestricted outbound access?
        ↓
Could outbound traffic support data exfiltration?

Many environments allow broad egress by default.

You should at least understand the risk.

Part 11 — Build an Egress Map

For an application, document expected outbound destinations.

Example:

Application VM
   │
   ├── Google APIs
   ├── Approved Update Repository
   └── Required External API

Anything else should be reviewed.

Part 12 — Review Public IP Addresses

Inventory workloads with external IP addresses.

For each public IP, ask:

Which workload?
        ↓
Why is public access required?
        ↓
Which ports are exposed?
        ↓
Could private connectivity work instead?

Public IP Review Table

Workload	Public IP	Required?	Exposure	Recommendation
Web VM	Yes	Yes	HTTPS	Keep/review
Backend VM	Yes	No	None expected	Remove
Admin VM	Yes	Review	SSH	Restrict

Part 13 — Private Workload Design

Backend workloads often do not require public IP addresses.

A preferred pattern may be:

Internet
   ↓
Load Balancer
   ↓
Private Application Workload

or:

Private VM
    ↓
Cloud NAT
    ↓
Internet

for outbound access.

Part 14 — Review Cloud NAT

If Cloud NAT is configured, identify:

Which subnet uses it
Which workloads depend on it
Why outbound internet access is required

Conceptually:

Private VM
    ↓
Private IP
    ↓
Cloud NAT
    ↓
Internet

The workload can reach external services without accepting direct inbound connections through a public IP.

Security Benefit

Cloud NAT helps separate:

Outbound Internet Access

from:

Direct Inbound Internet Exposure

These are not the same requirement.

Part 15 — Review Routes

Inspect routing information.

Understand where traffic can travel.

Ask:

Which default routes exist?
Are there custom routes?
Are routes expected?
Could traffic reach unintended destinations?

Conceptually:

Source
   ↓
Route Decision
   ↓
Next Hop
   ↓
Destination

Part 16 — Review Segmentation

Consider whether production workloads are appropriately separated.

Example:

Frontend Tier
     ↓
Backend Tier
     ↓
Database Tier

Instead of:

Every Workload
      ↕
Every Other Workload

The second model increases potential lateral movement.

Part 17 — Test Required Communication

In your authorized lab environment, validate that intended communication works.

For example:

Web Tier
   ↓
Backend Tier

should succeed if required.

But:

Unrelated Workload
      ↓
Sensitive Backend

should not automatically succeed.

The exact test method depends on the services used in your lab.

Part 18 — Controlled Misconfiguration Exercise

Create or identify a temporary lab firewall rule that is intentionally broader than required.

For example, conceptually:

Broad Source
    ↓
Administrative Port
    ↓
Test Workload

Do not expose a sensitive workload.

The objective is to practice identifying and remediating the condition.

Part 19 — Assess the Misconfiguration

Document:

Finding:
Overly Broad Ingress Rule

Source:
Broad Network Range

Port:
Administrative Port

Target:
Test Workload

Business Requirement:
Restricted Administration

Assessment:
Rule is broader than required.

Part 20 — Apply Least-Privilege Networking

Remediate the controlled rule.

Move from:

Any Source
   ↓
Administrative Port
   ↓
Workload

toward:

Approved Source
      ↓
Required Port
      ↓
Specific Workload

Validate the Remediation

Confirm:

Approved Communication
      ↓
Still Works

and:

Unauthorized Source
      ↓
Blocked

This is network least privilege.

Part 21 — Review Internet-Facing Services

For each internet-facing workload, document:

Business purpose
Required protocol
Required port
Authentication
Load balancing
Logging
Backend exposure

A public service should not imply that every backend resource must also be public.

Part 22 — Review Load Balancer Architecture

Where load balancing is used, understand the flow.

Internet
   ↓
Load Balancer
   ↓
Backend Service
   ↓
Application Workload

This often allows the backend to be more tightly controlled than directly exposing every instance.

Part 23 — Review Private Google API Access

Some private workloads may need Google APIs without using public addresses.

Understand the concept of allowing private resources to access required Google services through appropriate private connectivity options.

Security design should distinguish between:

Access to Google Services

and:

General Internet Exposure

Part 24 — Review Private Service Connectivity

Enterprise environments may use private connectivity for managed services.

The design objective is often:

Application
     ↓
Private Network Path
     ↓
Managed Service

instead of unnecessary public exposure.

Part 25 — Review Hybrid Connectivity

If your environment uses:

Cloud VPN
Cloud Interconnect
Hybrid routing

review the trust relationship between on-premises and Google Cloud.

Ask:

Which on-premises networks can reach GCP?
        ↓
Which GCP networks can reach on-premises?
        ↓
Is that access required?

Private connectivity does not automatically mean trusted connectivity.

Part 26 — Shared VPC Security

In enterprise architectures, networking may be centralized.

Conceptually:

Host Project
    ↓
Shared VPC
    ↓
Service Projects

This separates:

Network Administration

from:

Application Administration

which can improve governance.

Part 27 — Review Network Administrative Access

IAM still matters in networking.

Identify who can:

Create firewall rules
Modify VPCs
Create routes
Change networking
Manage Shared VPC

A perfectly designed network can become insecure if too many identities can modify it.

Network + IAM Security

Always think:

Network Configuration
        +
Who Can Change It

Both are part of the security assessment.

Part 28 — Review Firewall Logging

Where appropriate, examine whether firewall activity is logged.

Network logs can help answer:

Was traffic allowed?

Was traffic denied?

Which source?

Which destination?

Which port?

This becomes valuable during incident response.

Part 29 — Review VPC Flow Logs

Where enabled and applicable, VPC Flow Logs can provide visibility into network communication.

They can help analysts understand:

Source
   ↓
Destination
   ↓
Protocol
   ↓
Traffic

The exact telemetry available depends on configuration.

Part 30 — Connect Network Logs to Cloud Logging

Return to Cloud Logging.

Review available network-related telemetry.

Your investigation may combine:

Firewall Configuration
        +
Firewall Logs
        +
VPC Flow Logs
        +
Cloud Audit Logs

This gives both:

Configuration View

and:

Activity View

Part 31 — Investigate a Firewall Change

Using Cloud Audit Logs, locate a network configuration change made during the lab.

Determine:

Who made the change
When
Which firewall rule
Which project
Whether it succeeded

Investigation Flow

Unexpected Exposure
      ↓
Identify Firewall Rule
      ↓
Review Audit Logs
      ↓
Identify Principal
      ↓
Determine Change Time
      ↓
Review Related Activity

This connects network security with incident response.

Part 32 — Review DNS Security Context

DNS can also provide useful network context.

At minimum understand:

Application
   ↓
DNS Resolution
   ↓
Destination

Unexpected DNS behavior can sometimes support security investigations.

The depth of DNS monitoring depends on the architecture.

Part 33 — Assess Lateral Movement Risk

Ask:

If one workload is compromised, what can it reach?

Use a conceptual map:

Compromised Web VM
        ↓
Backend?
Database?
Management Systems?
Other Projects?

The more unnecessary connectivity available, the larger the potential blast radius.

Part 34 — Build a Network Attack Path

A possible attack path may look like:

Internet
   ↓
Exposed Workload
   ↓
Compromise
   ↓
Broad Internal Connectivity
   ↓
Sensitive Backend

The security objective is to break unnecessary paths.

Part 35 — Apply Defense in Depth

Do not rely only on firewall rules.

Network security may combine:

IAM
 +
Firewall Controls
 +
Private Connectivity
 +
Workload Security
 +
Logging
 +
Monitoring

This is defense in depth.

Part 36 — Identify Common Network Findings

Typical findings may include:

Finding 1 — Broad Administrative Access

Source:
0.0.0.0/0

Port:
Administrative Port

Finding 2 — Unnecessary Public IP

Backend Workload
      ↓
External IP

with no business need.

Finding 3 — Broad Internal Rule

Entire VPC
   ↓
All Ports
   ↓
All Workloads

Finding 4 — Missing Network Logging

Important traffic cannot be adequately investigated.

Finding 5 — Excessive Network Administration

Too many principals can modify security-sensitive networking controls.

Part 37 — Rate Network Findings

Use a simple model.

Critical

Direct exposure can lead to serious compromise of highly sensitive resources.

High

Broad public or administrative exposure with meaningful impact.

Medium

Weak segmentation, monitoring, or unnecessarily broad connectivity.

Low

Security hygiene or governance issue with limited immediate impact.

Part 38 — Document a Professional Finding

Example:

Finding:
Public Administrative Access to Compute Workload

Risk:
High

Affected Resource:
test-admin-vm

Evidence:
Firewall configuration permits administrative connectivity from a broad internet source range.

Impact:
Internet-based attackers may attempt unauthorized access against the workload.

Recommendation:
Remove broad public access and restrict administration to an approved private or trusted management path.

Validation:
Confirm approved administrators retain required access and unauthorized sources are blocked.

Part 39 — Create a Network Findings Table

Finding	Resource	Risk	Recommendation
Broad ingress	Admin VM	High	Restrict source
Public backend IP	Backend VM	Medium	Remove public IP
Weak segmentation	Backend tier	Medium	Narrow communication
Missing logs	Firewall	Medium	Enable required visibility

Part 40 — Build Your Network Security Review Workflow

Use:

01 Understand Architecture
        ↓
02 Inventory VPCs
        ↓
03 Review Subnets
        ↓
04 Review Routes
        ↓
05 Review Ingress
        ↓
06 Review Egress
        ↓
07 Identify Public IPs
        ↓
08 Review Private Connectivity
        ↓
09 Validate Segmentation
        ↓
10 Review Network IAM
        ↓
11 Review Logging
        ↓
12 Identify Findings
        ↓
13 Remediate
        ↓
14 Validate

Part 41 — Security Review Questions

For every network, ask:

Exposure

Which resources are public?
Why?

Ingress

Who can connect?
Which ports are open?

Egress

Where can workloads connect?

Segmentation

Can unrelated workloads communicate?

Identity

Who can change network configuration?

Visibility

Are network events logged?

Resilience

Does the architecture still meet business availability needs?

Part 42 — Think Like a Security Engineer

Do not ask only:

Is this port open?

Ask:

Why is it open?
        ↓
To whom?
        ↓
On which workload?
        ↓
For how long?
        ↓
What happens if that workload is compromised?

That is the difference between configuration review and security assessment.

Part 43 — Network Security Baseline

Create a simple secure baseline for your lab.

Example:

Internet-Facing Workloads:
Only required public services

Administrative Access:
Restricted

Backend Workloads:
Private

Database:
Private

Firewall Rules:
Minimum required ports

Network Administration:
Limited identities

Logging:
Enabled where required

Compare the actual environment to the baseline.

Part 44 — Validate Required Business Traffic

Security controls should not break legitimate workloads.

After remediation, test:

Required User Traffic
       ↓
Works

Required Application Traffic
       ↓
Works

Unauthorized Traffic
       ↓
Blocked

This is an important security engineering principle.

Part 45 — Review Findings With Business Context

Suppose you identify:

Port 443
Open to Internet

That alone is not enough to call it a vulnerability.

If the resource is a public web application, it may be expected.

Security findings require context.

Compare:

Internet → HTTPS → Public Web Service

with:

Internet → Database Port → Internal Database

The second situation carries very different risk.

Lab Challenge 1 — Find the Broadest Firewall Rule

Review the lab environment.

Identify the firewall rule with the broadest exposure.

Document:

Source
Port
Target
Business purpose
Risk

Lab Challenge 2 — Find an Unnecessary Public IP

Identify a workload with public connectivity.

Determine whether that exposure is genuinely required.

Recommend an alternative if not.

Lab Challenge 3 — Map Application Traffic

Create a diagram:

User
  ↓
Frontend
  ↓
Backend
  ↓
Database

For every arrow, document:

Source
Destination
Protocol
Port
Requirement

Lab Challenge 4 — Perform Least-Privilege Remediation

Take one intentionally broad lab firewall rule.

Narrow the:

Source
Port
Target

Then validate connectivity.

Lab Challenge 5 — Investigate a Network Change

Use Cloud Logging to identify who modified a firewall rule.

Record:

Principal
Time
Action
Resource

Lab Challenge 6 — Assess Lateral Movement

Assume one test VM becomes compromised.

Document every other workload it could potentially reach.

Then recommend controls to reduce that reach.

Lab Challenge 7 — Create a Network Security Report

Produce a short report containing:

Network Architecture
      ↓
Public Exposure
      ↓
Firewall Findings
      ↓
Segmentation Findings
      ↓
Logging Findings
      ↓
Recommendations

Lab Success Criteria

You have successfully completed this lab when you can:

Explain the VPC architecture
Identify subnet roles
Review routing
Assess ingress rules
Assess egress
Identify public exposure
Review Cloud NAT
Evaluate network segmentation
Identify overly broad rules
Review network-related IAM
Review network logs
Trace a firewall change to a principal
Perform controlled remediation
Validate connectivity
Document findings

Interview Questions to Practice

After completing this lab, you should be able to answer:

What is a Google Cloud VPC?
How do subnets work in Google Cloud?
How do firewall rules protect workloads?
What is the difference between ingress and egress?
Why is 0.0.0.0/0 security-sensitive?
Is all internet-facing traffic insecure?
How would you secure SSH or RDP access?
Why should backend workloads avoid unnecessary public IPs?
What is Cloud NAT?
What security benefit does Cloud NAT provide?
How would you review firewall rules for least privilege?
What is network segmentation?
Why are separate subnets not sufficient by themselves?
What is Shared VPC?
How would you secure hybrid connectivity?
What are VPC Flow Logs used for?
Why is firewall logging important?
How would you investigate an unexpected firewall change?
How can IAM affect network security?
How would you assess lateral movement risk?
What is the difference between public access and outbound internet access?
How would you validate a network security remediation?
How would you secure a three-tier application in GCP?
What network controls would you review during an incident?
How would you reduce the blast radius of a compromised workload?

Cloud Network Security Engineer Mindset

Whenever you review networking, use:

Source
  ↓
Destination
  ↓
Protocol
  ↓
Port
  ↓
Identity
  ↓
Business Requirement
  ↓
Security Decision

Then ask:

Is this path necessary?

Can it be narrowed?

Can the destination remain private?

Is the activity visible?

Who can change the rule?

Key Takeaway

A secure Google Cloud network is not simply a network where connectivity works.

It is a network where:

Required Communication
        ↓
Allowed

and:

Unnecessary Communication
        ↓
Blocked

while security teams retain enough visibility to investigate changes and suspicious activity.

That is the foundation of least-privilege networking in Google Cloud.

Clean Up

After completing the lab:

Remove intentionally broad firewall rules
Remove disposable public IPs
Remove temporary test resources
Restore approved network settings
Confirm required application traffic still works
Verify no unnecessary exposure remains

Keep your findings and architecture diagram as part of your practical security portfolio.

What’s Next?

➡️ Lab 05 — Security Command Center

In the final GCP Security lab, you will bring together the skills from:

Cloud Logging
      +
IAM Security
      +
Incident Response
      +
Network Security

and use Security Command Center to understand centralized cloud security posture and findings.

You will learn how to:

Navigate Security Command Center
Review security findings
Understand misconfiguration and threat signals
Prioritize findings
Assess affected resources
Correlate findings with IAM and logging
Track remediation
Build a practical cloud security posture review

This final lab will complete the core Google Cloud Security hands-on sequence.