In security, “least privilege” is like espresso the right amount gives you a perfect cup, but too much or too little ruins the pour.

In Azure networking, least privilege is enforced with Network Security Groups (NSGs) for local segmentation, and Azure Virtual Network Manager (AVNM) Security Admin Rules (SARs) for consistent global enforcement. Together, they keep your environment locked down without drowning you in manual rule management.

NSGs: Your Local Filter

NSGs sit at the subnet or network interfaces and:

• Filter traffic by priority, protocol, and source/destination.
• Allow/deny only the flows you intend.
• Form the backbone of micro segmentation.

Example:

• Web NSG → allow inbound 443 from internet.
• App NSG → allow inbound 443 only from Web VNet.
• Data NSG → allow inbound 1433 only from App VNet.

That’s least privilege in action, but it can get messy across dozens of VNets.

Scaling with AVNM + Security Admin Rules

When you want to apply rules consistently across many VNets and regions, AVNM steps in:

• Network Groups: logical collections of VNets (e.g. “All Prod”).
• Security Admin Rules: policies that apply across those groups.
• Precedence: SARs override NSGs — a deny at SAR level always wins.

Typical baseline SARs:

• Deny inbound RDP (3389) everywhere.
• Deny inbound SMB (445) everywhere.
• Only allow internet HTTPS to web‑tier VNets.

This lets you enforce non‑negotiable org‑wide controls, while teams still use NSGs for local traffic shaping.

Real‑World Impact

A dev team might accidentally allow RDP inbound on a test VNet. With SARs in place, the global deny 3389 rule overrides them. You get consistent protection without having to patrol every NSG.

That mix — NSGs for segmentation, SARs for global enforcement — is what makes “least privilege” stick in large Azure estates.

Implementation Snapshot

Azure Portal

• Create Network Groups (by environment).
• Apply a Security Admin Config for global denies.
• Validate rule enforcement alongside existing NSGs.

Bicep Example (abridged)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

// AVNM with Security Admin Rules
resource vnetMgr 'Microsoft.Network/networkManagers@2023-12-01' = {
  name: 'corp-network-manager'
  location: resourceGroup().location
  properties: {
    networkManagerScopeAccesses: ['Connectivity','SecurityAdmin']
    networkManagerScopes: { subscriptions: [subscription().id] }
  }
}

resource prodGroup 'Microsoft.Network/networkManagers/networkGroups@2023-12-01' = {
  name: 'prod-vnets'
  parent: vnetMgr
}

resource secConfig 'Microsoft.Network/networkManagers/securityAdminConfigurations@2023-12-01' = {
  name: 'baseline-sec'
  parent: vnetMgr
}

resource deny3389 'Microsoft.Network/networkManagers/securityAdminConfigurations/ruleCollections@2023-12-01' = {
  name: 'deny-rdp'
  parent: secConfig
  properties: {
    appliesToGroups: [ { networkGroupId: prodGroup.id } ]
    rules: [
      {
        name: 'Deny-RDP'
        direction: 'Inbound'
        priority: 100
        action: 'Deny'
        protocol: 'Tcp'
        destinationPort: '3389'
        source: { addressPrefix: '*' }
        destination: { addressPrefix: '*' }
      }
    ]
  }
}

Gotchas & Best Practices

• SARs override NSGs — test carefully before rollout.
• Scope SARs to the right VNets/regions using Network Groups.
• Use NSGs for application‑specific rules, SARs for baseline “thou shalt nots”.
• Pair with Azure Policy to ensure all VNets join the correct AVNM groups.

Want the Full Deep Dive?

This is the 100ml pour. If you want the full espresso shot — including detailed rule conflicts, precedence tests, and operational lessons check out my separate article:
Azure AVNM Security Admin Rules vs NSGs in the Real World

Learn More

• Azure Virtual Network Manager overview
• Security Admin rules explainer
• Network Security Groups