03 Azure Network Security

Azure network security is not just about blocking ports. It is about controlling traffic paths, reducing unnecessary exposure, enforcing segmentation, protecting private access, and understanding how network controls interact.

Welcome to the Azure Network Security Lab.

In the previous labs, you focused on:

Azure RBAC
Microsoft Entra ID Security

Now you will focus on:

Which systems can communicate, through which paths, and under what controls?

You will move from:

I understand VNets and NSGs

to:

I can assess, secure, troubleshoot, and explain Azure network architecture.

This lab is designed for learners preparing for roles such as:

Azure Security Engineer
Cloud Security Engineer
Network Security Engineer
Azure Administrator
Cloud Security Consultant
DevSecOps Engineer
Cloud Security Architect

🎯 Mission Information

Item	Details
Lab	Azure Network Security
Difficulty	Beginner → Intermediate
Estimated Time	2–3 hours
Primary Focus	Azure Network Security & Segmentation
Target Roles	Azure Security Engineer, Cloud Security Engineer, Network Security Engineer
Certification Alignment	AZ-104, AZ-500, AZ-305
Career Skill	Network Security Assessment & Troubleshooting
Environment	Personal Azure lab subscription
Cost Awareness	Some networking services may generate charges

⚠️ Cost Awareness

Be careful with resources such as:

Azure Firewall
Application Gateway
Bastion
VPN Gateway
public IPv4 addresses
Private Endpoints
data transfer

For a low-cost lab, you can complete most exercises using:

one VNet
two or three subnets
Network Security Groups
route tables
one or two small test VMs if needed
Network Watcher tools
diagnostic logs

Delete unnecessary resources when finished.

🏢 Mission Scenario

You have joined an organization as a junior Azure Security Engineer.

The organization is migrating a business application into Azure.

The initial environment was deployed quickly, and the security team is concerned that:

workloads may be unnecessarily public
NSGs may contain overly broad rules
private systems may have internet-facing paths
segmentation between tiers may be weak
network routes may not be understood
PaaS resources may be accessed through public endpoints unnecessarily
east-west traffic is not clearly controlled
network telemetry is insufficient

Your mission is to perform a structured Azure network-security review and improve the environment.

🎯 Mission Objectives

By the end of this lab, you should be able to:

explain Azure VNets
design subnets
review IP addressing
configure NSGs
review inbound and outbound rules
understand rule priorities
identify public exposure
understand route tables
distinguish NSGs from Azure Firewall
understand Private Endpoints
understand service access concepts
review VNet peering
troubleshoot connectivity
use network-monitoring tools
create security findings
recommend remediation

📚 Prerequisites

You should understand:

IP addressing
CIDR
TCP/UDP
common ports
routing
firewalls
Azure subscriptions
resource groups
Azure VMs
Azure RBAC basics

Recommended previous learning:

AZ-900
AZ-104
AZ-500
Azure RBAC Lab
Microsoft Entra ID Security Lab

🧠 Azure Network Security Mental Model

For every connection ask:

Source
   ↓
Destination
   ↓
Route
   ↓
NSG / Firewall
   ↓
Public or Private Path
   ↓
Service Listener
   ↓
Return Path
   ↓
Telemetry

Ask:

Source

Where is the traffic coming from?

Destination

Where is it going?

Route

Is there a valid route?

Security Control

Does an NSG or firewall allow it?

Exposure

Does this connection need to use the public internet?

Return Path

Can traffic return?

Monitoring

Can you see what happened?

🏗️ Lab Architecture

Build or conceptually review a simple three-tier environment:

Internet
   ↓
Frontend Subnet
   ↓
Application Subnet
   ↓
Data Subnet

A stronger architecture should follow:

Public Entry
    ↓
Controlled Frontend
    ↓
Private Application
    ↓
Private Data

Not:

Internet
  ↓
Every Workload

🧪 Task 1 — Review Existing Virtual Networks

Navigate to:

Azure Portal → Virtual networks

Review existing VNets.

Record:

VNet name
resource group
Region
address space
subnet count
peerings
DNS settings

Create:

VNet	Address Space	Subnets	Region	Purpose

🧠 Security Question

Ask:

Why does this VNet exist?

Unowned or undocumented networks become difficult to secure.

🧪 Task 2 — Create a Dedicated Lab VNet

Create:

Name:
ghc-network-security-vnet

Address Space:
10.20.0.0/16

Use a dedicated lab resource group.

🧪 Task 3 — Create Subnets

Create:

FrontendSubnet
10.20.1.0/24

ApplicationSubnet
10.20.2.0/24

DataSubnet
10.20.3.0/24

🧠 Why Separate Subnets?

Subnets create logical boundaries that support:

routing
NSG application
tier separation
private endpoints
operational organization

But simply creating multiple subnets does not automatically create security.

Controls must enforce the intended trust model.

🧪 Task 4 — Draw the Intended Traffic Flow

Document:

Internet
   ↓
Frontend
   ↓
Application
   ↓
Data

Then define what should not happen:

Internet ─X→ Application

Internet ─X→ Data

Frontend ─X→ Database Admin Ports unless required

🧠 Security Engineering Principle

Before configuring network rules, define:

Which communication should be allowed?

Then build controls around that requirement.

🧪 Task 5 — Review Public IP Usage

Navigate to:

Public IP addresses

Inventory:

Resource	Public IP	Required?	Reason

Ask:

Does this resource actually need public addressing?

🚨 Common Findings

Potential issues include:

VM with public IP
management interface exposed
database accessible publicly
old unused public IP

🧪 Task 6 — Create a Frontend NSG

Create:

ghc-frontend-nsg

Associate it with the frontend subnet or test network interface as appropriate.

Allow only the traffic required for your scenario.

Example:

HTTPS 443
Source:
Internet / approved test source

If you use HTTP for a lab example, understand that production applications should normally prefer HTTPS.

🧪 Task 7 — Review Default NSG Rules

Examine the default NSG rules.

Understand that custom rules interact with default behavior.

Review:

inbound defaults
outbound defaults
virtual-network rules
internet-related rules

🧠 Important

Do not memorize default-rule names only.

Understand the traffic behavior they permit or deny.

🧪 Task 8 — Understand NSG Rule Priority

Custom NSG rules use priorities.

Lower numbers represent higher priority.

Example:

Priority 100
Allow HTTPS

Priority 200
Deny Specific Source

Priority 300
Allow Something Else

🧠 Troubleshooting Question

If two rules appear to conflict, which one is evaluated first?

Review priority.

🧪 Task 9 — Create an Application NSG

Create:

ghc-application-nsg

Allow application traffic only from the frontend tier.

Example concept:

Frontend Subnet
      ↓
TCP 8080
      ↓
Application Subnet

Do not allow:

Internet
 ↓
TCP 8080
 ↓
Application Tier

unless there is a documented requirement.

🧪 Task 10 — Create a Data NSG

Create:

ghc-data-nsg

Allow database traffic only from the application tier.

Concept:

Application Subnet
       ↓
Database Port
       ↓
Data Subnet

🧠 Least-Privilege Networking

Network least privilege means:

Permit only the source, destination, protocol, and port required for the business flow.

🧪 Task 11 — Identify an Overly Broad Rule

Create or inspect a controlled test rule such as:

Source:
Internet

Destination Port:
3389

Action:
Allow

or:

Source:
Any

Destination Port:
22

Action:
Allow

Do not leave it enabled longer than necessary.

🚨 Why This Matters

Public administrative exposure increases attack surface for:

password attacks
credential stuffing
exploitation
scanning

🧪 Task 12 — Remediate Administrative Exposure

Instead of public administrative access, consider design options such as:

Azure Bastion
VPN/private administrative network
Just-In-Time concepts where appropriate
restricted trusted source ranges

🧠 Security Question

Ask:

Why does an administrator need direct public access to this workload?

If there is no strong answer, reduce exposure.

🧪 Task 13 — Review NSG Outbound Rules

Security reviews often focus too heavily on inbound traffic.

Check outbound behavior.

Ask:

Can this workload reach any destination on the internet?

🚨 Egress Matters

A compromised workload may need outbound access for:

command and control
payload retrieval
data exfiltration

🧪 Task 14 — Define Required Egress

For the application tier, document which destinations are actually needed.

Example:

Destination	Port	Purpose	Required?
Azure service	443	API access	Yes
Entire internet	Any	Unknown	No

🧠 Security Principle

Do not restrict egress blindly if the application genuinely needs outbound connectivity.

Understand dependencies first.

🧪 Task 15 — Review Effective Security Rules

On a test network interface, inspect effective security rules where available.

Use this to understand:

subnet-level NSG
NIC-level NSG
inherited/effective rules

🧠 Troubleshooting Value

When multiple NSGs apply, always investigate the effective result.

🧪 Task 16 — Review Route Tables

Navigate to:

Route tables

Create or review a route table.

Understand routes such as:

VNet local
internet
virtual appliance
gateway

🧠 Routing Question

Ask:

Where does traffic go after leaving this subnet?

🧪 Task 17 — Associate a Route Table With a Lab Subnet

Create a controlled test route table if appropriate.

Example:

ghc-app-route-table

Associate it with:

ApplicationSubnet

Do not create disruptive routes in production environments.

🧪 Task 18 — Understand User-Defined Routes

User-defined routes can direct traffic toward:

virtual appliances
firewalls
custom network paths

Conceptually:

Application Subnet
       ↓
UDR
       ↓
Firewall / Inspection
       ↓
Destination

🧠 Security Architecture Question

Ask:

Which traffic must pass through centralized inspection?

🧪 Task 19 — Understand Azure Firewall

Azure Firewall provides centralized network-security capabilities.

Conceptually:

Spoke VNet
   ↓
Route
   ↓
Azure Firewall
   ↓
Approved Destination

🧠 NSG vs Azure Firewall

At a high level:

NSG	Azure Firewall
Distributed filtering	Centralized security control
Applied to subnet/NIC context	Central inspection/policy use cases
Basic L3/L4-style controls	Broader centralized capabilities
No need to deploy firewall appliance	Dedicated managed security service

Do not think:

One replaces the other.

They often solve different layers of the design.

🧪 Task 20 — Design a Hub-and-Spoke Security Architecture

Create a conceptual design:

               Internet
                  ↓
             Azure Firewall
                  ↓
                Hub VNet
             /      |      \
            ↓       ↓       ↓
          Prod     Dev    Shared
         Spoke    Spoke   Services

🧠 Why Use Hub-and-Spoke?

Possible benefits:

centralized connectivity
shared security controls
inspection
hybrid integration

Potential trade-offs:

complexity
cost
routing dependencies

🧪 Task 21 — Review VNet Peering

If your lab contains multiple VNets, create or review peering.

Understand:

VNet A
  ↔
VNet B

🧠 Security Question

Ask:

What new trust path does this peering create?

Network connectivity should be intentional.

🚨 Common Mistake

Teams may assume peering means:

all communication is automatically appropriate.

It only creates connectivity potential.

NSGs and other controls still matter.

🧪 Task 22 — Create a Peering Review Matrix

Source VNet	Destination VNet	Purpose	Required?	Risk

🧪 Task 23 — Understand Private Endpoints

Private Endpoints allow supported Azure services to receive a private IP inside your VNet.

Conceptually:

Application
   ↓
Private IP
   ↓
Private Endpoint
   ↓
Azure PaaS Service

🧠 Security Benefit

Private Endpoints can help reduce dependence on public service endpoints.

But remember:

Private connectivity does not replace authorization.

Still review:

identity
RBAC
service configuration
DNS
logging

🧪 Task 24 — Design a Private Storage Access Scenario

Scenario:

An internal application needs access to Azure Storage, but security does not want public network exposure.

Design:

ApplicationSubnet
      ↓
Private Endpoint
      ↓
Storage Account

Then consider:

private DNS
RBAC
public access settings
application identity

🧪 Task 25 — Compare Private Endpoint and Public Access

Create:

Design	Exposure	Security Consideration
Public endpoint	Public network path	Must tightly control access
Private Endpoint	Private VNet path	Still requires authorization

🧪 Task 26 — Understand Service Endpoints

Review the concept of service endpoints if included in your environment or learning path.

Understand how they differ conceptually from Private Endpoints.

🧠 Interview-Level Comparison

Be prepared to explain:

Private Endpoint gives the service a private endpoint presence in your VNet.

Do not reduce the comparison to:

both make things private.

🧪 Task 27 — Review DNS With Private Endpoints

Private connectivity often depends on DNS resolving the service hostname to the correct private address.

🧠 Troubleshooting Question

If:

routing works
NSGs look correct
Private Endpoint exists

but the application still resolves the public service IP:

investigate DNS.

🧪 Task 28 — Review Load Balancer / Application Gateway Concepts

Understand the broad difference between:

Azure Load Balancer
Application Gateway

For web workloads, Application Gateway can operate at the application layer and may support web-security capabilities depending on configuration.

🧠 Architecture Question

Ask:

Is the requirement simple network load balancing or application-aware web traffic management?

🧪 Task 29 — Design a Secure Web Architecture

Create:

Internet
   ↓
Application Gateway / Approved Frontend
   ↓
Frontend/Application Tier
   ↓
Private Data Tier

Consider:

TLS
NSGs
private data access
logging

🧪 Task 30 — Review Network Watcher

Explore Azure Network Watcher capabilities available in your environment.

Understand tools that may help with:

connectivity troubleshooting
next-hop analysis
IP flow verification
topology/diagnostics

🧠 Security Engineer Principle

Do not guess network problems when evidence is available.

🧪 Task 31 — Use IP Flow Verify Conceptually or Practically

Test whether a specific flow should be allowed or denied.

Example:

Source:
Frontend VM

Destination:
Application VM

Port:
8080

Determine:

allowed?
denied?
which rule determines the result?

🧪 Task 32 — Review Next Hop

When troubleshooting route behavior, determine the next hop.

Possible results may include:

virtual network
internet
virtual appliance
gateway

🧠 Troubleshooting Value

This helps answer:

Is traffic being routed where I think it is?

🧪 Task 33 — Troubleshooting Scenario 1

Scenario:

Frontend VM cannot reach Application VM on TCP 8080.

Use:

Source IP
 ↓
Destination IP
 ↓
Subnet
 ↓
Route
 ↓
Source NSG
 ↓
Destination NSG
 ↓
OS Firewall
 ↓
Application Listener
 ↓
Return Path

🧪 Task 34 — Troubleshooting Scenario 2

Scenario:

Application can access a storage account through its public endpoint, but the Private Endpoint configuration does not work.

Investigate:

Private Endpoint state
subnet
DNS resolution
network controls
storage access settings
identity authorization

🧪 Task 35 — Troubleshooting Scenario 3

Scenario:

A VM has a public IP but is not reachable over RDP.

Do not assume the NSG is the only issue.

Check:

public IP
NSG
route
VM state
OS firewall
RDP service
correct credentials

🧪 Task 36 — Troubleshooting Scenario 4

Scenario:

Traffic unexpectedly bypasses the intended firewall.

Investigate:

route tables
UDR associations
more specific routes
peering behavior
subnet design

🧠 Network Troubleshooting Framework

Use:

Source
 ↓
DNS
 ↓
Route
 ↓
NSG
 ↓
Firewall
 ↓
Destination
 ↓
Service
 ↓
Return Path

🧪 Task 37 — Review Network Logging

Review network-related diagnostic capabilities available to your lab.

Consider:

NSG flow-related telemetry where supported
Azure Monitor
firewall logs
application gateway logs
diagnostic settings

🧠 Monitoring Question

Ask:

If suspicious traffic occurred yesterday, could we investigate it today?

If the answer is no, visibility may be insufficient.

🧪 Task 38 — Create a Network Security Finding

Example:

Finding ID:
AZNET-001

Title:
RDP Exposed to the Internet

Severity:
High

Affected Resource:
Frontend VM / NSG

Observation:
TCP 3389 is allowed from an unrestricted internet source.

Risk:
Internet hosts can directly attempt administrative access to the workload.

Recommendation:
Remove unrestricted public RDP and use approved private or controlled administrative-access methods.

🧪 Task 39 — Create a Segmentation Finding

Finding ID:
AZNET-002

Title:
Application and Data Tiers Lack Network Segmentation

Severity:
High

Observation:
Application and data subnets allow overly broad east-west communication.

Risk:
Compromise of one workload may enable unnecessary lateral access to sensitive systems.

Recommendation:
Restrict communication to documented application flows using least-privilege network controls.

🧪 Task 40 — Create a Public PaaS Exposure Finding

Finding ID:
AZNET-003

Title:
Sensitive PaaS Resource Uses Unnecessary Public Network Access

Severity:
Medium / High depending on data sensitivity

Observation:
An internal application accesses a sensitive Azure service through its public endpoint although private connectivity is technically feasible.

Risk:
The design increases external network exposure and expands the attack surface.

Recommendation:
Evaluate Private Endpoint-based access and restrict unnecessary public network paths.

🧪 Task 41 — Create an Unrestricted Egress Finding

Finding ID:
AZNET-004

Title:
Sensitive Workload Has Unrestricted Outbound Internet Access

Severity:
Medium / High

Risk:
A compromised workload may communicate with attacker-controlled infrastructure or exfiltrate data.

Recommendation:
Identify required outbound dependencies and implement appropriate egress controls without disrupting legitimate application traffic.

📊 Network Risk Rating

Use:

Reachability
+
Exposure
+
Service Sensitivity
+
Attack Surface
+
Business Impact
=
Risk

🔴 Critical

Examples:

sensitive database directly reachable from internet
publicly exposed management plane with serious impact potential

🟠 High

Examples:

public RDP/SSH
major segmentation failure
sensitive unrestricted lateral access

🟡 Medium

Examples:

excessive outbound access
unnecessary public PaaS path
missing network visibility

🔵 Low

Examples:

stale NSG
unused route
missing documentation

🧪 Task 42 — Build a Network Security Assessment Table

Control	Status	Risk	Recommendation
VNet architecture
Subnet segmentation
Public IP exposure
NSG least privilege
Administrative ports
Outbound access
Route tables
VNet peering
Private Endpoints
Network telemetry

🧪 Task 43 — Build an Exposure Matrix

Resource	Public IP/Endpoint	Open Port	Required?	Risk

🧪 Task 44 — Build a Traffic Matrix

Document intended traffic.

Source	Destination	Port	Business Purpose	Allowed?
Internet	Frontend	443	Web traffic	Yes
Internet	Application	8080	None	No
Application	Data	DB port	Application data	Yes

This is very useful for real network reviews.

🚨 Incident Scenario — Suspicious Outbound Traffic

Scenario:

A production VM is communicating with an unexpected external IP.

Investigate:

Identify VM
   ↓
Network Telemetry
   ↓
Destination / Port
   ↓
NSG / Egress Path
   ↓
Associated Identity
   ↓
Related Azure Activity
   ↓
Containment Decision

🧠 Ask

which process or application should generate this traffic?
is the destination expected?
did a recent network change enable it?
is other suspicious activity present?

🚨 Incident Scenario — Unexpected NSG Change

Scenario:

A previously private application suddenly has TCP 22 open from the internet.

Investigate:

who changed the rule
when
affected NSG
affected resources
related identity activity
subsequent access attempts

🎤 Azure Network Security Interview Questions

Practise without notes.

Fundamentals

1. What is an Azure VNet?

2. What is a subnet?

3. Why segment workloads into multiple subnets?

4. What is an NSG?

5. How do NSG priorities work?

Security

6. Why is public RDP/SSH risky?

7. Why should outbound traffic be reviewed?

8. What is network segmentation?

9. How would you secure a three-tier application?

Routing

10. What is a route table?

11. What is a user-defined route?

12. Why would traffic be routed through a firewall?

Firewall

13. NSG vs Azure Firewall?

14. When might centralized network inspection be appropriate?

Private Connectivity

15. What is a Private Endpoint?

16. Why use Private Endpoints?

17. Does a Private Endpoint remove the need for RBAC?

18. What role does DNS play with Private Endpoints?

Connectivity

19. What is VNet peering?

20. What security considerations exist with VNet peering?

21. What is hub-and-spoke architecture?

Troubleshooting

22. Two VMs cannot communicate. What would you check?

23. A Private Endpoint exists but the application resolves the public endpoint. What would you investigate?

24. An NSG appears correct but traffic still fails. What else would you check?

🚨 Scenario Interview Question 1

A VM has RDP open to 0.0.0.0/0. What would you do?

A strong answer should include:

confirm business need
assess current exposure
review previous access
restrict/remove public administrative access
use approved private/controlled alternatives
validate remediation

🚨 Scenario Interview Question 2

An internal application must access Azure Storage but policy prohibits public network access.

Discuss:

Private Endpoint
private DNS
RBAC/authorization
storage network configuration

🚨 Scenario Interview Question 3

A web tier needs to reach an application tier, but the application tier should not be reachable directly from the internet.

Design:

Internet
   ↓
Frontend
   ↓
Application

with least-privilege NSG rules.

🚨 Scenario Interview Question 4

An organization has many VNets and wants centralized traffic inspection.

Discuss:

hub-and-spoke
routing
centralized firewall
operational complexity
cost
availability

🚨 Scenario Interview Question 5

NSG rules allow traffic but the application still cannot connect.

Use:

DNS
 ↓
Routing
 ↓
NSG
 ↓
Firewall
 ↓
OS Firewall
 ↓
Service Listener
 ↓
Return Path

🧠 Interview Answer Framework

For network questions use:

Source
   ↓
Destination
   ↓
Route
   ↓
Network Control
   ↓
Service
   ↓
Return Path
   ↓
Telemetry

💬 Interview Tip

Avoid:

“Check the NSG.”

A stronger answer is:

“I would first confirm the source, destination, expected port, and intended network path. Then I would verify routes, effective NSG rules, centralized firewall controls if present, service availability, DNS, and the return path, using Azure networking diagnostics where appropriate.”

That sounds like a Cloud Security Engineer.

📁 Portfolio Evidence

After completing the lab, create a sanitized portfolio package.

Include:

Network Architecture Diagram

Show:

Internet
   ↓
Frontend Subnet
   ↓
Application Subnet
   ↓
Data Subnet

Traffic Matrix

Document permitted flows.

Exposure Matrix

Document public resources.

NSG Review

Identify broad rules.

Network Findings

Create 3–5 findings.

Remediation

Explain how each risk was reduced.

Troubleshooting Case

Document one connectivity issue from:

symptom → investigation → root cause → remediation.

📝 Resume Examples

Instead of:

Knowledge of Azure networking.

Use:

Built and assessed segmented Azure VNet environments with subnets, NSGs, route tables, VNet peering, and private-access patterns, then documented network-security findings and remediation.

Or:

Troubleshot Azure connectivity issues by analyzing routing, effective NSG rules, DNS, service availability, and network paths using Azure networking diagnostics.

⭐ Job-Readiness Check

After this lab, you should be able to:

explain VNets
design subnets
configure NSGs
explain rule priority
identify public exposure
review outbound access
understand route tables
explain NSG vs Azure Firewall
understand VNet peering
explain Private Endpoints
understand private DNS requirements
troubleshoot connectivity
create network findings
recommend remediation

If your entire Azure network-security strategy still means:

add an NSG,

repeat the lab.

The goal is:

understand the complete traffic path, reduce unnecessary exposure, enforce appropriate segmentation, and validate both allowed and denied communication.

🧹 Lab Clean-Up

After completing your evidence collection:

remove temporary public IPs
remove intentionally insecure NSG rules
delete unnecessary test VMs
remove unused NSGs
remove temporary route tables
remove unnecessary peerings
delete temporary Private Endpoints if no longer required
remove expensive networking resources created only for testing
review Azure Cost Management for unexpected ongoing charges

🏆 Mission Complete

You have now practised:

VNet Architecture
      ↓
Subnet Segmentation
      ↓
Public Exposure Review
      ↓
NSG Security
      ↓
Routing
      ↓
Private Connectivity
      ↓
Network Troubleshooting
      ↓
Security Findings
      ↓
Remediation

These capabilities are fundamental for:

Azure Security Engineers
Cloud Security Engineers
Azure Administrators
Network Security Engineers
Cloud Security Consultants
Cloud Security Architects

🚀 What’s Next?

You now understand the major Azure identity and network security boundaries:

Microsoft Entra ID
      ↓
Azure RBAC
      ↓
Azure Network Security

The next step is to use Microsoft’s cloud-security posture and workload-protection capabilities to identify weaknesses and prioritize remediation.

➡️ Next: Microsoft Defender for Cloud Lab

In the next lab, you will work with:

Defender for Cloud
cloud-security posture
security recommendations
secure score concepts
regulatory/compliance views
workload protection
security alerts
vulnerability findings
resource prioritization
security findings
remediation
cloud-security interview scenarios