Implementing Azure Security Groups

I recently completed a practical exercise on Azure Security Groups, applying real-world configurations to harden access and streamline network governance. In this post I am trying to document a hands‑on exercise on Azure security group configuration to illustrate how Application Security Groups (ASGs) and Network Security Groups (NSGs) work together to provide least‑privilege, workload‑centric network security. The walk‑through covers creating ASGs/NSGs, associating them to subnets and NICs, validating connectivity via Cloud Shell, and enabling a scoped SSH rule to demonstrate controlled access.

Why this matters

Modern cloud networking requires controls that are flexible, scalable, and aligned with application boundaries. ASGs allow administrators to group VMs by workload, while NSGs provide the traffic policing rules. Designing security by workload rather than by IP simplifies management and reduces blast radius when enabling access.

Prerequisites

An Azure subscription with appropriate admin privileges.
A resource group .
A virtual network (example: VNET) with a subnet yoursubnet.
A Linux VM with a NIC in the resource group. Ensure the VM has a public IP if you intend to test SSH from the public internet (for lab/testing only).
Access to Azure Cloud Shell (Bash).

Security note: Do not expose administrative credentials or production IPs in public posts. Use placeholders when documenting examples and avoid hard‑coding secrets.

Step‑by‑step implementation

1) Create an Application Security Group (ASG)

In the Azure portal search bar, type Application security groups and open the service.
Click Create.
Select the target Resource Group .
Enter the name (Application security group) and confirm Region = your region.
Review and Create.

Why: ASGs provide a logical grouping for workloads so NSG rules can reference groups rather than IP addresses.

2) Create a Network Security Group (NSG)

In the Azure portal search bar, open Network security groups.
Click Create.
Select the same Resource Group and region.
Enter a name of your application security group.
Review and Create.

Note: Deployment typically takes 1–2 minutes.

3) Associate the NSG to the subnet

Open the Network Security Group resource in the portal.
Under Settings, select Subnets.
Click Associate, choose the virtual network (VNET) and the frontend subnet, then OK.

Best practice: Associate an NSG either to the subnet or to NICs—not both—unless you have a deliberate reason and understand rule precedence.

4) Associate the ASG to the VM NIC

Open the network interface (NIC) attached to VM1.
Under the NIC settings, edit Application security groups and add your-security-group.
Save the configuration.

Why: Scoping NSG rules to an ASG lets you target traffic to specific workloads attached to NICs.

5) Capture the VM public IP (for testing)

Record the VM’s public IP address from the VM overview blade (do not publish this IP in public documentation). You will use this for SSH testing from Cloud Shell or another client.

6) Validate initial connectivity using Cloud Shell

Open Azure Cloud Shell (Bash) and attempt an SSH connection:

ssh azureadmin@<public_ip>

The connection will likely time out or be refused at this stage because no inbound NSG rule permits SSH.

7) Create an inbound NSG rule scoped to the ASG

In the networksecuritygruop blade, go to Inbound security rules and click Add.
Configure the rule:
- Destination: Application security group
- Destination application security groups: Your-Security-Group
- Destination port ranges: 22
- Protocol: TCP
- Name: AllowSSH
- Leave other values at sensible defaults (Priority, Source, etc.), then Add.

Principle: The rule enables SSH only to the workload members of the ASG, implementing least‑privilege access.

8) Re‑test SSH connection

Run the SSH command again from Cloud Shell and authenticate using the VM’s login credentials (or use an SSH key if configured). A successful connection confirms that the NSG rule and ASG scoping are working as intended.

Troubleshooting checklist

Confirm the NSG is associated to the correct subnet (or NIC) and that the ASG is attached to the target NIC.
Verify NSG effective security rules from the VM NIC blade to inspect rule precedence and conflicts.
Ensure the VM firewall (e.g., ufw or iptables) allows SSH.
If using a public IP, make sure it is assigned and in the same region.
Check Azure activity logs and NSG flow logs for diagnostic data.

Best practices & recommendations

Prefer Azure Bastion or VPN + private endpoints rather than exposing SSH over the internet for production workloads.
Use Just‑In‑Time (JIT) VM access for temporary, auditable shell access.
Log NSG flow data to a Log Analytics workspace for auditing and incident response.
Use Role‑Based Access Control (RBAC) and Privileged Identity Management to limit who can create/modify NSGs/ASGs.
Keep rules simple, named clearly, and documented in a governance artefact.

Key takeaways

ASGs and NSGs together enable policy‑by‑workload and minimize reliance on static IP addresses.
Scoping inbound rules to ASGs supports least‑privilege access patterns and improves manageability.
Always validate connectivity and inspect effective rules when results differ from expectations.

Step-by-step brief:

Created an Application Security Group (ASG) and Network Security Group (NSG) in East US.
Associated the NSG to the frontend subnet for subnet-level control.
Attached the ASG to the VM’s NIC to target workload traffic.
Opened Azure Cloud Shell (Bash) to validate connectivity.
Attempted SSH—observed expected timeout due to default deny.
Added inbound NSG rule “AllowSSH” (TCP 22) scoped to the ASG.
Retested and confirmed successful, least-privilege SSH access.

Conclusion

This practical exercise demonstrates a robust pattern for securing network access in Azure: group workloads using ASGs and control traffic with NSGs scoped to those groups. When combined with bastion/JIT access, logging, and governance, this approach supports a secure, auditable, and maintainable cloud network posture.