Scenario
Your team is modernising an existing Azure environment where several virtual machines share the same subnet. One of these VMs hosts a sensitive workload that stores confidential data. During a security review, the team discovered that every VM in the subnet can freely communicate with this sensitive machine, creating a lateral‑movement risk.
Re‑architecting the network into multiple subnets would be ideal, but it isn’t feasible right now. You’ve been asked to implement a solution that isolates the sensitive VM without moving it and without disrupting the rest of the environment.
Lab Objectives
- Deploy two VMs into the same subnet
- Configure Azure Bastion for secure access
- Apply a NIC‑level NSG to isolate a sensitive VM
- Create rules that allow only approved traffic
- Validate that lateral movement is blocked
Prerequisites
- An active Azure subscription
- Permissions to create networking and compute resources
- Basic understanding of Azure VNETs and NSGs
Deploy the Lab Environment
Create the following resources:
Virtual Network
- One VNET with at least one subnet
- Both VMs will be deployed into this same subnet
Azure Bastion
- Deploy into a dedicated
AzureBastionSubnet - Provides secure RDP/SSH access without public IPs
Virtual Machines
Deploy two Linux VMs into the same subnet:
- vm‑sensitive
- Represents a high‑value workload
- Will be isolated using a NIC‑level NSG
- vm‑regular
- Represents a standard workload
- Should not have access to vm‑sensitive
Confirm both VMs can be accessed via Bastion.
Understand the Need for NIC‑Level NSGs
In Azure, all resources inside a VNET and especially inside the same subnet can communicate freely by default.
Subnet‑level NSGs are ideal for broad segmentation, but sometimes:
- You cannot move VMs into new subnets
- You need to isolate a single VM inside a shared subnet
- You want to enforce Zero Trust at the workload level
This is where NIC‑level NSGs become essential.
Apply a NIC‑Level NSG to the Sensitive VM
Create a new NSG and associate it only with the NIC of vm‑sensitive.
Add the following rules:
Rule 1: Allow SSH from Bastion
- Source: Bastion Subnet
- Destination: vm‑sensitive
- Port: 22
- Action: Allow
- Purpose: Permit secure admin access
Rule 2: Deny All Other Traffic
- Source: Any
- Destination: Any
- Port: Any
- Action: Deny
- Purpose: Block all lateral movement inside the subnet
This ensures that only Bastion can reach vm‑sensitive.
Validate Isolation
Perform the following tests:
Test 1: Bastion → vm‑sensitive
- Connect via SSH
- Expected result: Connection succeeds
Test 2: vm‑regular → vm‑sensitive
From vm‑regular, attempt:
ssh user@<vm-sensitive-private-ip>
- Expected result: Connection fails
- Reason: The NIC‑level NSG blocks all traffic except Bastion
This confirms that vm‑sensitive is fully isolated inside the shared subnet.
Results
With the NIC‑level NSG applied:
- Only Bastion can access vm‑sensitive
- vm‑regular cannot reach vm‑sensitive
- Lateral movement inside the subnet is prevented
- Zero Trust segmentation is enforced without redesigning the network
Conclusion
This lab demonstrates how NIC‑level NSGs can isolate a high‑value VM even when it shares a subnet with other workloads. This approach is ideal when:
- You cannot restructure the network
- You need to protect a sensitive VM immediately
- You want to enforce Zero Trust at the workload level
