While it has been and continues to be relatively easy to manage and secure networks when on-premises as they are usually managed by a dedicated team, it becomes a little bit more complex when doing the same on cloud environments. This is a result of the creation and management of cloud resources being delegated to different teams in charge of the deployed workload. This is one of the main benefits of cloud services, delegating the deployment and configuration of resources they need for their services, applications or projects, to the business, reducing the time to market.
So, how can you ensure your virtual networks stay protected and configured while you could possibly lose visibility and control over them?
You may decide to have a central governance team to enforce security rules, but this is an endless task as each individual NGS will have to be reviewed and updated constantly.
You may rely on the workloads owners to implement the security rules but then again you may be at risk.
Finally, you could deploy NGS rules using Azure Policy, which has notifications if they are being changed. This is probably the best option (so far) but you still can’t enforce the security rules and you can get overwhelmed with notifications.
This is where Azure Virtual Network Manager (AVNM) comes to the rescue.
Azure Virtual Network Manager – currently in preview – is scalable network management solution to manage virtual network connectivity and security rules.
One of the advantages of it, is the scoping of the network manager can be set at any level (from management groups to the subscriptions).
You can implement multiple virtual network managers as long as they don’t have the same scope (management group or subscription) and feature combination (connectivity and security); meaning you can deploy 2 different AVNM at your management group level, one to configure the network connectivity and the other for the security rules but you cannot do it if both AVNM manage the configuration of connectivity and the security rules at the same time.
In case of conflict, the configuration with the higher-level scope will prevail. For example, you scope an AVNM at your management group level to block inbound traffic on RDP and SSH ports, and then you have a second AVNM scoped at the subscription level which allows inbound traffic on RDP port, then the virtual networks in this subscription will apply the configuration from the management group and will be blocking both RDP and SSH ports.
So, in a little bit more detail, what can we do?
The connectivity configuration part of AVNM allows you to define a group of networks (either assigned or dynamically) to communicate with each other – either hub/spoke or mesh configuration. For example, you may want to deny virtual networks used for development or testing to communicate with each other, including with production networks, while you want to allow your production networks to communicate.
The security configuration allows you to define inbound and outbound security rules to ensure only allowed network traffic can transit to and from the virtual networks.
A common global configuration is to block inbound traffic on management ports (RDP and/or SSH) and block any outbound traffic to internet except for HTTP/HTTPS and DNS.
So how is it going to work as the network connectivity and security configurations may be already in place?
Well, when configured, the network configuration for hub and spoke you can choose to delete existing peering.
For the security configuration it is a little bit tricky as it will depend on the action (allow, always allow or deny).
For both allow and always allow the traffic will be authorised by the network manager. Then the always allow option will overwrite the NSG rules defined, while the allow option will then be controlled by the NSG rules as shown by the below diagram.
As a bonus, here is a list of ports you should have blocked or at least controlled – some are obviously well known.
