Network security is a top concern for organizations today. We are faced with increasing breaches, threats, and cyber risk. With Azure Stack HCI 21H2, you can define granular segmentation for your applications and workloads, based on source and destination network ranges and protect them from both external and internal attacks. While this provides protection from threats, management becomes difficult (especially at scale) as users will need to know the network ranges of all their applications and services. With Azure Stack HCI 22H2, we have made this very simple with custom user-defined security tags. Assign any custom security tags to classify your VMs, and then apply Network Security Groups (NSGs) based on the tags to restrict communication to/from external as well as internal sources.
What was available with Azure Stack HCI 21H2
With Azure Stack HCI 21H2, a distributed firewall enables administrators to define network security groups to restrict access for workloads attached to traditional VLAN networks and overlay networks. This is a network layer firewall, allowing or restricting access based on source and destination IP addresses, source and destination ports and network protocol. You can read more about this here.
IMPORTANT: The microsegmentation policies can be applied to all Azure Stack HCI workloads attached to traditional VLAN networks.
Let me take a simple example. If you look at the figure above, we have couple of applications in the HCI cluster, one web app and one IOT app. Attacker lands on the user’s personal device (through malware, phishing, exploiting vulnerabilities in home routers, etc.), gets full remote control over the web app and can easily manipulate them or leak data. With Azure Stack HCI 21H2, you can define Network Security Groups to prevent web app from communicating with the IOT app. This is shown below.
Limitations with 21H2 capabilities
This is all great, but there are a few limitations with this approach. Firstly, your security policies are tied to network constructs, so you will need to know which apps are hosted on which network segments. You will need to have a fair understanding of your network infrastructure and architecture. Secondly, since your policy has network elements which will be unique for every app, you cannot templatize the policy to use for other similar apps. And finally, if you decommission your old app and provision a new app in the same network segment, you will have to modify your policy.
Solution – Simplified Network Security Groups with security tags
With Azure Stack HCI 22H2, we are Introducing tag based segmentation. Now, you can label your workload VMs with tags of your choice and then apply security policies based on these tags. These tags can be completely custom. As an example, the workload VM below has three tags: It is part of the Production environment, it belongs to Exchange application, and even with the application, it belongs to the MailBox app tier.
Now, your Network Security Group (NSG) source can be a tag or a network segment, and the NSG destination can be a tag or a network segment. With this, you no longer need to track the network segments where your applications are hosted.
Taking the same example as above, you can see how the NSG policy becomes simplified below.
This feature is available as part of Azure Stack HCI 22H2. And this is fully integrated with Windows Admin Center for management. Read more about this feature here.
Let’s look at this in action in Windows Admin Center. In the demo, I am using the same example of a web app VM and an IOT app VM.
As you can see, with security tags, management and provisioning of the Network Security Groups becomes much simpler. Please try it out, and if you have any questions or feedback, please send to sdn_feedback@microsoft.com