Lesson: Network Security Group (NSG) Design

Introduction: What is an NSG?

In cloud infrastructure, a Network Security Group (NSG) acts as a virtual firewall for your cloud resources. It contains a list of security rules that allow or deny inbound and outbound network traffic to resources connected to virtual networks (VNets).

Why do we need them? Without NSGs, your cloud resources would be exposed to the public internet or internal lateral movement without any filtering. NSGs provide the "Zero Trust" foundation required to secure cloud environments, ensuring that only authorized traffic reaches your applications, databases, and management interfaces.

How NSGs Work: The Mechanics

An NSG works by evaluating traffic based on a 5-tuple:

1. Source/Destination IP address
2. Source/Destination Port
3. Protocol (TCP, UDP, ICMP, etc.)
4. Direction (Inbound or Outbound)
5. Priority (Rules are processed in order from lowest number to highest number)

The Priority System

Rules are processed in priority order. Once traffic matches a rule, processing stops. If you have a rule with priority 100 that allows traffic and another with priority 200 that denies it, the traffic will be allowed. Always remember: Lower numbers = Higher priority.

Default Rules

Every NSG comes with default rules that cannot be removed but can be overridden:

• AllowVnetInBound: Allows communication between resources within the same VNet.
• AllowAzureLoadBalancerInBound: Allows health probes from the Azure Load Balancer.
• DenyAllInBound: The final "fail-safe" that blocks everything not explicitly allowed.

Practical Example: Designing a 3-Tier Architecture

Imagine a standard web application architecture consisting of a Web Tier, an App Tier, and a Database Tier. You should not use one single NSG for everything. Instead, apply granular NSGs to each subnet.

1. Web Tier NSG (Public Facing)

• Inbound: Allow Port 80/443 from Internet (Source).
• Outbound: Allow traffic to the App Tier subnet.

2. App Tier NSG (Internal)

• Inbound: Allow Port 8080 from the Web Tier subnet only.
• Outbound: Allow traffic to the Database Tier subnet.

3. Database Tier NSG (Locked Down)

• Inbound: Allow Port 5432 (PostgreSQL) from the App Tier subnet only.
• Outbound: Deny all (or restrict to necessary updates).

Infrastructure as Code (IaC) Implementation

Using Terraform is the industry standard for managing NSGs to ensure consistency and version control.

# Example: Defining an NSG Rule for a Web Subnet
resource "azurerm_network_security_rule" "allow_https" {
  name                        = "AllowHTTPSInbound"
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "443"
  source_address_prefix       = "Internet"
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.main.name
  network_security_group_name = azurerm_network_security_group.web_nsg.name
}

Pro Tip: When using IaC, define your rules in a variable file or a module to avoid hard-coding IP addresses, which can lead to configuration drift.

Best Practices for NSG Design

1. Principle of Least Privilege: Never use Any or * as a source or destination if you can avoid it. Specify exact subnets or IP ranges.
2. Use Application Security Groups (ASGs): Instead of managing IP addresses, use ASGs to group virtual machines by function (e.g., ASG-Web, ASG-DB). Rules can then reference the ASG name instead of specific IPs.
3. Log Everything: Enable NSG Flow Logs. This allows you to monitor traffic patterns and perform forensic analysis if a security incident occurs.
4. Keep it Simple: Avoid creating hundreds of rules in a single NSG. If an NSG becomes too complex, your architecture is likely too complex; consider segmenting your network into smaller subnets.
5. Test with Network Watcher: Use tools like "IP Flow Verify" in Azure Network Watcher to test if a packet is allowed or denied without needing to manually inspect every rule.

Common Pitfalls to Avoid

• The "Deny All" Trap: Creating a custom rule that denies everything at priority 100, effectively blocking your own management access (SSH/RDP) or internal communication.
• Ignoring Outbound Traffic: Many architects focus entirely on Inbound rules. However, egress filtering is critical to prevent compromised servers from "phoning home" to a Command & Control (C2) server.
• Overlapping Rules: Creating conflicting rules where an "Allow" rule is unintentionally overridden by a higher-priority "Deny" rule. Always use the "Effective Security Rules" view in your cloud portal to visualize the final result.
• Hard-coding IPs: Using hard-coded public IPs in rules makes your infrastructure fragile and difficult to migrate. Use Service Tags (e.g., Sql, Storage, AzureLoadBalancer) provided by the cloud provider instead.

Key Takeaways

• NSGs are stateful: If you allow inbound traffic, the return traffic is automatically allowed. You do not need to create a matching outbound rule for the return trip.
• Granularity is key: Apply NSGs at the subnet level rather than the individual NIC level whenever possible to maintain easier management and visibility.
• Prioritize security: Always adopt a "Deny by Default" posture. Explicitly allow only the traffic required for the application to function.
• Leverage Automation: Use IaC (Terraform, Bicep, ARM) to deploy NSGs. This prevents human error and ensures that your security posture is reproducible across development, staging, and production environments.

By mastering NSG design, you move from simply "connecting" resources to "securing" them, which is the cornerstone of professional cloud infrastructure engineering.