Skip to content

Commit 4db0d80

Browse files
Merge pull request #256611 from mbender-ms/pr/mbender-ms/256376
Pr/mbender ms/256376
2 parents bde8813 + cba483b commit 4db0d80

File tree

2 files changed

+66
-27
lines changed

2 files changed

+66
-27
lines changed

articles/virtual-network-manager/concept-security-admins.md

Lines changed: 56 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -11,13 +11,13 @@ ms.custom: template-concept, ignite-fall-2021, engagement-fy23
1111

1212
# Security admin rules in Azure Virtual Network Manager
1313

14-
In this article, you'll 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](concept-network-groups.md). You learn about what security admin rules are, how they work, and when to use them.
14+
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](concept-network-groups.md). You learn about what security admin rules are, how they work, and when to use them.
1515

1616
[!INCLUDE [virtual-network-manager-preview](../../includes/virtual-network-manager-preview.md)]
1717

1818
## What is a security admin rule?
1919

20-
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 network manager instance; thus, security admin rules cannot apply to virtual networks not managed by a network manager.
20+
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 network manager instance; thus, security admin rules can't apply to virtual networks not managed by a network manager.
2121

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

@@ -81,25 +81,25 @@ Based on the industry study and suggestions from Microsoft, we recommend custome
8181

8282
| **Port** | **Protocol** | **Description** |
8383
| --- | ---- | ------- |
84-
| **20** | TCP | Unencrypted FTP Traffic |
85-
| **21** | TCP | Unencrypted FTP Traffic |
86-
| **22** | TCP | SSH. Potential brute force attacks |
87-
| **23** | TCP | TFTP allows unauthenticated and/or unencrypted traffic |
88-
| **69** | UDP | TFTP allows unauthenticated and/or unencrypted traffic |
89-
| **111** | TCP/UDP | RPC. Unencrypted authentication allowed |
90-
| **119** | TCP | NNTP for unencrypted authentication |
91-
| **135** | TCP/UDP | End Point Mapper, multiple remote management services |
92-
| **161** | TCP | SNMP for unsecure / no authentication |
93-
| **162** | TCP/UDP | SNMP Trap - unsecure / no authentication |
94-
| **445** | TCP | SMB - well known attack vector |
95-
| **512** | TCP | Rexec on Linux - remote commands without encryption authentication |
96-
| **514** | TCP | Remote Shell - remote commands without authentication or encryption |
97-
| **593** | TCP/UDP | HTTP RPC EPMAP - unencrypted remote procedure call |
98-
| **873** | TCP | Rsync - unencrypted file transfer |
99-
| **2049** | TCP/UDP | Network File System |
100-
| **3389** | TCP | RDP - Common brute force attack port |
101-
| **5800** | TCP | VNC Remote Frame Buffer over HTTP |
102-
| **5900** | TCP | VNC Remote Frame Buffer over HTTP |
84+
| **20** | TCP | Unencrypted FTP Traffic |
85+
| **21** | TCP | Unencrypted FTP Traffic |
86+
| **22** | TCP | SSH. Potential brute force attacks |
87+
| **23** | TCP | TFTP allows unauthenticated and/or unencrypted traffic |
88+
| **69** | UDP | TFTP allows unauthenticated and/or unencrypted traffic |
89+
| **111** | TCP/UDP | RPC. Unencrypted authentication allowed |
90+
| **119** | TCP | NNTP for unencrypted authentication |
91+
| **135** | TCP/UDP | End Point Mapper, multiple remote management services |
92+
| **161** | TCP | SNMP for unsecure / no authentication |
93+
| **162** | TCP/UDP | SNMP Trap - unsecure / no authentication |
94+
| **445** | TCP | SMB - well known attack vector |
95+
| **512** | TCP | Rexec on Linux - remote commands without encryption authentication |
96+
| **514** | TCP | Remote Shell - remote commands without authentication or encryption |
97+
| **593** | TCP/UDP | HTTP RPC EPMAP - unencrypted remote procedure call |
98+
| **873** | TCP | Rsync - unencrypted file transfer |
99+
| **2049** | TCP/UDP | Network File System |
100+
| **3389** | TCP | RDP - Common brute force attack port |
101+
| **5800** | TCP | VNC Remote Frame Buffer over HTTP |
102+
| **5900** | TCP | VNC Remote Frame Buffer over HTTP |
103103
| **11211** | UDP | Memcached |
104104

105105
### Management at scale
@@ -110,9 +110,44 @@ New resources are protected along with existing resources. For example, if you a
110110

111111
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.
112112

113+
## Nonapplication of security admin rules
114+
115+
In most instances, security admin rules are applied 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. These requirements are enforced by the service's network intent policy.
116+
117+
### Nonapplication of security admin rules at virtual network level
118+
119+
By default, security admin rules aren't applied to a virtual network containing the following services:
120+
121+
- [Azure SQL Managed Instances](/azure/azure-sql/managed-instance/connectivity-architecture-overview#mandatory-security-rules-with-service-aided-subnet-configuration)
122+
- Azure Databricks
123+
124+
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](/dotnet/api/microsoft.azure.management.network.models.networkintentpolicybasedservice?view=azure-dotnet) .NET class. When set, *Allow* rules in your security configuration will be applied to this virtual network. All *Deny* rules will not be applied on this virtual network. Virtual networks without these services can continue using *Allow* and *Deny* rules.
125+
126+
You can create a security configuration with *Allow* rules only and deploy it to your virtual networks with [Azure PowerShell](/powershell/module/az.network/new-aznetworkmanagersecurityadminconfiguration#example-1) and [Azure CLI](/cli/azure/network/manager/security-admin-config#az-network-manager-security-admin-config-create-examples).
127+
128+
> [!NOTE]
129+
> When multiple Azure Virtual Network Manager instances apply different settings in the `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices` class to the same virtual network, the setting of the network manager instance with the highest scope will be used.
130+
> Let's say you have two virtual network managers. The first network manager is scoped to the root management group and has a security configuration with set to *AllowRulesOnly* in the `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices` class. The second virtual network manager is scoped to a subscription under the root management group and uses the default field of *None* in it's security configuration. When both configurations apply security admin rules to the same virtual network, the *AllowRulesOnly* setting will be applied to the virtual network.
131+
132+
### Nonapplication of security admin rules at subnet level
133+
134+
Similarly, there are some services that don't apply security admin rules at the subnet level when those subnets' virtual networks are a part of a network group targeted by a security admin configuration. Those services include:
135+
136+
- Azure Application Gateway
137+
- Azure Bastion
138+
- Azure Firewall
139+
- Azure Route Server
140+
- Azure VPN Gateway
141+
- Azure Virtual WAN
142+
- Azure ExpressRoute Gateway
143+
144+
> [!NOTE]
145+
> If you want to apply security admin rules on subnets containing an Azure Application Gateway, ensure each subnet only contains gateways that have been provisioned with [network isolation](../application-gateway/application-gateway-private-deployment.md) enabled. If a subnet contains an Azure Application Gateway without network isolation, security admin rules won't be applied to this subnet.
146+
113147
## Security admin fields
114148

115149
When you define a security admin rule, there are required and optional fields.
150+
116151
### Required fields
117152

118153
#### Priority

articles/virtual-network-manager/faq.md

Lines changed: 10 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -87,17 +87,17 @@ You can view Azure Virtual Network Manager settings under **Network Manager** fo
8787

8888
Should a regional outage occur, all configurations applied to current resources managed persist, and you can't modify existing configurations, or create new configuration.
8989

90-
### Can a virtual network managed by Azure Virtual Network Manager be peered to a non-managed virtual network?
90+
### Can a virtual network managed by Azure Virtual Network Manager be peered to a nonmanaged virtual network?
9191

9292
Yes, Azure Virtual Network Manager is fully compatible with pre-existing hub and spoke topology deployments using peering. This means that you won't need to delete any existing peered connections between the spokes and the hub. The migration occurs without any downtime to your network.
9393

9494
### Can I migrate an existing hub and spoke topology to Azure Virtual Network Manager?
9595

96-
Yes, migrating existing VNets to AVNM’s hub and spoke topology is very easy and requires no down time. Customers can [create a hub and spoke topology connectivity configuration](how-to-create-hub-and-spoke.md) of the desired topology. When the deployment of this configuration is deployed, virtual network manager will automatically create the necessary peerings. Any pre-existing peerings set up by users will remain intact, ensuring there's no downtime.
96+
Yes, migrating existing VNets to AVNM’s hub and spoke topology is easy and requires no down time. Customers can [create a hub and spoke topology connectivity configuration](how-to-create-hub-and-spoke.md) of the desired topology. When the deployment of this configuration is deployed, virtual network manager will automatically create the necessary peerings. Any pre-existing peerings set up by users remain intact, ensuring there's no downtime.
9797

9898
### How do connected groups differ from virtual network peering regarding establishing connectivity between virtual networks?
9999

100-
In Azure, VNet peering and connected groups are two methods of establishing connectivity between virtual networks (VNets). While VNet peering works by creating a 1:1 mapping between each peered VNet, connected groups use a new construct that establishes connectivity without such a mapping. In a connected group, all virtual networks are connected without individual peering relationships. For example, if VNetA, VNetB, and VNetC are part of the same connected group, connectivity is enabled between each VNet without the need for individual peering relationships.
100+
In Azure, virtual network peering and connected groups are two methods of establishing connectivity between virtual networks (VNets). While virtual network peering works by creating a 1:1 mapping between each peered virtual network, connected groups use a new construct that establishes connectivity without such a mapping. In a connected group, all virtual networks are connected without individual peering relationships. For example, if VNetA, VNetB, and VNetC are part of the same connected group, connectivity is enabled between each virtual network without the need for individual peering relationships.
101101

102102
### Do security admin rules apply to Azure Private Endpoints?
103103

@@ -121,18 +121,22 @@ No, an Azure Virtual WAN hub isn't supported as the hub in a hub and spoke topol
121121

122122
### My Virtual Network isn't getting the configurations I'm expecting. How do I troubleshoot?
123123

124-
#### Have you deployed your configuration to the VNet's region?
124+
#### Have you deployed your configuration to the virtual network's region?
125125

126126
Configurations in Azure Virtual Network Manager don't take effect until they're deployed. Make a deployment to the virtual networks region with the appropriate configurations.
127127

128128
#### Is your virtual network in scope?
129129

130130
A network manager is only delegated enough access to apply configurations to virtual networks within your scope. Even if a resource is in your network group but out of scope, it doesn't receive any configurations.
131131

132-
#### Are you applying security rules to a VNet containing Azure SQL Managed Instances?
132+
#### Are you applying security rules to a virtual network containing Azure SQL Managed Instances?
133133

134134
Azure SQL Managed Instance has some network requirements. These are enforced through high priority Network Intent Policies, whose purpose conflicts with Security Admin Rules. By default, Admin rule application is skipped on VNets containing any of these Intent Policies. Since *Allow* rules pose no risk of conflict, you can opt to apply *Allow Only* rules. If you only wish to use Allow rules, you can set AllowRulesOnly on `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices`.
135135

136+
#### Are you applying security rules to a virtual network or subnet that contains services blocking security configuration rules?
137+
138+
Certain services such as Azure SQL Managed Instance, Azure Databricks and Azure Application Gateway require specific network requirements to function propertly. By default, security admin rule application is skipped on [VNets and subnets containing any of these services](./concept-security-admins.md#nonapplication-of-security-admin-rules). Since *Allow* rules pose no risk of conflict, you can opt to apply *Allow Only* rules by setting the security configurations' `AllowRulesOnly`field on `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices` .NET class.
139+
136140
## Limits
137141

138142
### What are the service limitations of Azure Virtual Network Manager?
@@ -165,7 +169,7 @@ Azure SQL Managed Instance has some network requirements. These are enforced thr
165169

166170
* Azure Virtual Network Manager policies don't support the standard policy compliance evaluation cycle. For more information, see [Evaluation triggers](../governance/policy/how-to/get-compliance-data.md#evaluation-triggers).
167171

168-
* The current preview of connected group has a limitation where traffic from a connected group cannot communicate with a private endpoint in this connected group if it has NSG enabled on it. However, this limitation will be removed once the feature is generally available.
172+
* The current preview of connected group has a limitation where traffic from a connected group can't communicate with a private endpoint in this connected group if it has NSG enabled on it. However, this limitation will be removed once the feature is generally available.
169173
## Next steps
170174

171175
Create an [Azure Virtual Network Manager](create-virtual-network-manager-portal.md) instance using the Azure portal.

0 commit comments

Comments
 (0)