Internet-facing virtual machines should be protected with network security groups

What does the recommendation "Internet-facing virtual machines should be protected with network security groups" check?

Flags any virtual machine that Defender for Cloud assesses as internet-facing (a public IP is attached to its network interface, or its traffic path otherwise reaches the internet) but has no network security group applied to filter inbound traffic. The underlying policy, AuditIfNotExists with ID f6de0be7, evaluates the NSG at both the subnet and the network interface, so a VM passes if either of those has a group bound. It does not look inside the NSG rules: a group that allows 0.0.0.0/0 on every port still satisfies this check, the control only confirms that some NSG exists in the path. It also does not cover VMs fronted by Azure Firewall or a third-party appliance when no NSG is attached.

Why does "Internet-facing virtual machines should be protected with network security groups" matter?

An internet-facing VM with no NSG accepts whatever Azure's default platform rules permit, leaving management ports such as RDP 3389 and SSH 22 reachable from any source on the public internet. These ports are scanned and brute-forced continuously by automated botnets, and an exposed VM is one weak or reused credential away from becoming a foothold for lateral movement, ransomware staging or crypto-mining that runs up your compute bill. The business consequence is rarely contained to one machine: a single compromised host on a flat subnet can pivot to databases and identities behind it. An NSG gives you a stateful choke point to deny the internet by default and admit only known sources, which is the difference between a workload that is merely running and one that is defensible.

How do I fix "Internet-facing virtual machines should be protected with network security groups"?

1. Bind a network security group to the VM's subnet first, since subnet-level association protects every machine in it and is the placement Microsoft recommends: az network vnet subnet update --resource-group <rg> --vnet-name <vnet> --name <subnet> --network-security-group <nsg>.
2. Inside the NSG, remove any rule that allows RDP or SSH from the internet (Any or 0.0.0.0/0 source) and instead scope inbound management to a corporate IP range, or front it with Azure Bastion or just-in-time VM access so the ports stay closed until needed.
3. Where a single VM needs rules its subnet peers should not share, also associate an NSG with that specific network interface, and bake the subnet-plus-NSG pattern into your Bicep or Terraform modules so new VMs ship protected rather than relying on this audit to catch them.

# 1. Close the highest-impact exposure first: delete any rule that
#    allows a management port from the whole internet.
for rule in $(az network nsg rule list -g prod-rg --nsg-name prod-nsg \
    --query "[?access=='Allow' && (sourceAddressPrefix=='*' || sourceAddressPrefix=='Internet') && (destinationPortRange=='3389' || destinationPortRange=='22')].name" -o tsv); do
  az network nsg rule delete -g prod-rg --nsg-name prod-nsg -n "$rule"
  echo "$rule: open management-port rule removed"
done

# 2. Add an explicit deny on the management ports as a backstop.
az network nsg rule create -g prod-rg --nsg-name prod-nsg \
  --name deny-mgmt-ports --priority 4000 --access Deny --direction Inbound \
  --protocol Tcp --source-address-prefixes Internet \
  --destination-port-ranges 22 3389

# 3. Gate the ports you still need behind just-in-time access.
#    JIT is configured via PowerShell or the portal; request access with the CLI:
az security jit-policy list -o table   # confirm the JIT policy is in place

# 4. Ratchet it shut: audit any VM left without an NSG (Defender built-in policy).
az policy assignment create \
  --name audit-internet-facing-nsg \
  --policy f6de0be7-9a8a-4b8a-b349-43cf02d22f7c \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"