Security admin rules in Azure Virtual Network Manager

In this article, you learn about security admin rules in Azure Virtual Network Manager. Security admin rules are used to define global network security rules that apply to all virtual networks within a network group. You learn about what security admin rules are, how they work, and when to use them.

What is a security admin rule?

Security admin rules are global network security rules that enforce security policies defined in the rule collection on virtual networks. These rules can be used to Allow, Always Allow, or Deny traffic across virtual networks within your targeted network groups. These network groups can only consist of virtual networks within the scope of your virtual network manager instance. Security admin rules can't apply to virtual networks not managed by a virtual network manager.

Here are some scenarios where security admin rules can be used:

With Azure Virtual Network Manager, you have a centralized location to manage security admin rules. Centralization allows you to define security policies at scale and apply them to multiple virtual networks at once.

How do security admin rules work?

Security admin rules allow or deny traffic on specific ports, protocols, and source/destination IP prefixes in a specified direction. When you define a security admin rule, you specify the following conditions:

• The priority of the rule
• The action to be taken (allow, deny, or always allow)
• The direction of traffic (inbound or outbound)
• The protocol to be used

To enforce security policies across multiple virtual networks, you create and deploy a security admin configuration. This configuration contains a set of rule collections, and each rule collection contains one or more security admin rules. Once created, you associate the rule collection with the network groups requiring security admin rules. The rules are then applied to all virtual networks contained in the network groups when the configuration is deployed. A single configuration provides a centralized and scalable enforcement of security policies across multiple virtual networks.

How security admin rules and network security groups (NSGs) are evaluated

Security admin rules and network security groups (NSGs) can be used to enforce network security policies in Azure. However, they have different scopes and priorities.#

Security admin rules are intended to be used by network admins of a central governance team, thereby delegating NSG rules to individual application or service teams to further specify security as needed. Security admin rules have a higher priority than NSGs and are evaluated before NSG rules.

NSGs, on the other hand, are used to filter network traffic to and from individual subnets or network interfaces. They're intended to be used by individual application or service teams to further specify security as needed. NSGs have a lower priority than security admin rules and are evaluated after security admin rules.

Security admin rules are currently applied at the virtual network level, whereas network security groups can be associated at the subnet and NIC level. This table shows these differences and similarities:

Security admin rules can perform three actions on traffic: Allow, Always Allow, and Deny. When created, Allow rules are evaluated first, followed by network security group rules. This action allows network security group rules to handle the traffic differently if needed.

If you create an Always Allow or Deny rule, traffic evaluation is terminated after the security admin rule is evaluated. With an Always Allow rule, the traffic goes directly to the resource and terminates further (and possibly conflicting) evaluation by NSG rules. This action can be useful for enforcing traffic and preventing denial by network security group rules. With a Deny rule, the traffic is stopped without being delivered to the destination. Security admin rules don't depend on NSGs, so they can be used to create default security rules on their own.

By using security admin rules and NSGs together, you can enforce network security policies at both the global and individual levels, ensuring that your virtual networks are secure and compliant with your organization's security policies.

Benefits of security admin rules

Security admin rules provide many benefits for securing your organization's resources. By using security admin rules, you can enforce allowed traffic and prevent denial by conflicting network security group rules. You can also create default security admin rules that don't depend on NSGs to exist. These default rules can be especially useful when application owners misconfigure or forget to establish NSGs. Additionally, security admin rules provide a way to manage security at scale, which reduces the operational overhead that comes with a growing number of network resources.

Protect high-risk ports

Based on the industry study and suggestions from Microsoft, we recommend customers restrict the traffic from outside using security admin rules for this list of high-risk ports. These ports are often used for the management of resources or unsecure/unencrypted data transmission and shouldn't be exposed to the internet. However, there are times when certain virtual networks and their resources need to allow traffic for management or other processes. You can create exceptions where needed. Learn how to blocking high-risk ports with exceptions for these types of scenarios.

Management at scale

Azure Virtual Network Manager provides a way to manage your security policies at scale with security admin rules. When you apply a security admin configuration to a network group, all of the virtual networks and their contained resources in the network groups’ scope receive the security admin rules in the policy.

New resources are protected along with existing resources. For example, if you add new VMs to a virtual network in the scope of a security admin rule, the VMs are automatically secured as well. Shortly after you deploy these VMs, security admin rules will be applied and protect them.

When new security risks are identified, you can deploy them at scale by creating a security admin rule to protect against the new risk and applying it to your network groups. Once this new rule is deployed, all resources in the scope of the network groups will be protected now and in the future.

Nonapplication of security admin rules

In most instances, security admin rules apply to all virtual networks and subnets within the scope of a network group's applied security configuration. However, there are some services that don't apply security admin rules due to the network requirements of the service. The service's network intent policy enforce these requirements.

Nonapplication of security admin rules at virtual network level

By default, security admin rules aren't applied to a virtual network containing the following services:

• Azure SQL Managed Instances
• Azure Databricks

When a virtual network contains these services, the security admin rules skip this virtual network. If you want Allow rules applied to this virtual network, you create your security configuration with the AllowRulesOnly field set in the securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices .NET class. When set, only Allow rules in your security configuration are applied to this virtual network. Deny rules aren't applied to this virtual network. Virtual networks without these services can continue using Allow and Deny rules.

You can create a security configuration with Allow rules only and deploy it to your virtual networks with Azure PowerShell and Azure CLI.

Nonapplication of security admin rules at subnet level

Similarly, some services don't apply security admin rules at the subnet level when the subnets' virtual network are within the scope of a security admin configuration. Those services include:

• Azure Application Gateway
• Azure Bastion
• Azure Firewall
• Azure Route Server
• Azure VPN Gateway
• Azure Virtual WAN
• Azure ExpressRoute Gateway

In this case, security admin rules don't affect the resources in the subnet with these services. However, other subnets within the same virtual network have security admin rules applied to them.

Security admin fields

When you define a security admin rule, there are required and optional fields.

Required fields

Priority

The priority of a security admin rule is an integer between 1 and 4096. The lower the value the higher the priority of the rule. For example, a deny rule with a priority of 10 overrides an allow rule with a priority of 20.

Action

You can define one of three actions for a security rule:

Direction

You can specify the direction of traffic for which the rule applies. You can define either inbound or outbound.

Protocol

Protocols currently supported with security admin rules are:

• TCP
• UDP
• ICMP
• ESP
• AH
• Any protocols

Optional fields

Source and destination types

• IP addresses: You can provide IPv4 or IPv6 addresses or blocks of address in CIDR notation. To list multiple IP address, separate each IP address with a comma.
• Service Tag: You can define specific service tags based on regions or a whole service. See Available service tags, for the list of supported tags.

Source and destination ports

You can define specific common ports to block from the source or to the destination. Here's a list of common TCP ports:

Next steps