In the previous article we took a look in to what capabilities a basic Azure network provides us. But it’s 2019, and just deploying a network and crossing our fingers it’ll all be alright just isn’t enough.
In this article we’re going to take a gander at what security options we can use to secure our deployed network.
Flash from the past
Well, about a week or so :).
We already know that with Azure networking you control the following items:
- IP address blocks
- DNS settings
- Security Policies
- Routing tables
On top of that, you get a choice to connect to your on-premises network with Secure VPN gateways or a private connection called Express Route.
One thing we always have to keep in mind with cloud service providers is that they operate a vast infrastructure. One you share with many other customers… Sounds scary, but the Microsoft Azure Team takes the fear away with isolated customer networks. They operate overly networks on top of their shared physical network so no customer can snoop on another customer!
This is done through Azure’s software defined networking. Something you’ll be familiar with if you’re running a data center with virtualization on-premises.
Network Security Group
So now we know that a VNet is a secure, logical network that gives us network isolation, as well as security controls which we treat like our on-premises network. Each customer on Azure is using their own IP address range, DNS settings, and possibly their own routing tables. But what if we want to control access inside our own Azure network?
Network Security Groups provide an answer to this conundrum. An NSG is a collection of network Access Control Lists (ACL) which allow a set of rules to be applied to all traffic. Whether entering or exiting a VM’s network interface. These rules can be based on 5 different attributes:
- Source IP address
- Source Port
- Destination IP address
- Destination Port
When defined, an NSG is associated either to a subnet or VM, these rules are enforced by the SDN stack, so no getting around them.
All rules defined in the NSG act as filters. In the inbound traffic path they are applied before traffic enters a vm/subnet. Outbound, they will be applied after traffic leaves the VM/subnet. So all of these rules are applied at the infrastructure level, meaning that no user process, or even the OS running in a VM, can alter the behavior of these rules. Any change made to an NSG is immediately applied to all linked resources.
These rules are also stateful, meaning that matching rules do not need to be made on the other side. So if you have an inbound rule to allow traffic on port 80, a matching rule on the outbound side is not required for packets to flow on the same port.
Alls NSG’s contain a set of default rules that allow connectivity within the virtual network, and outbound to the internet. You can overwrite these rules, but be wary. Just like with RBAC, applying rules without thinking them through could result in a not so fun evening…
Rules are based on priority. meaning that rules with a small value are processed before rules with larger values. This isn’t too different from the way any firewall out there works :).
Azure provides you with a set of default tags, like INTERNET (Public IP Address space outside the virtual network) and VIRTUAL_NETWORK (the entire network address space of the tenant.)
To VM or SubNet?
As we mentioned before, an NSG can be applied to a Virtual Machine, or to a subnet. Sometimes it can even be applied to both!.
Attaching to a VM
When you have traffic patterns which are very different between virtual machines in a subnet, it will be better to attach an NSG to a virtual machine.
Attaching to a Subnet
When all the machines in a subnet have identical traffic patters, it’ll be better to to have the NSG attached to the subnet. Less work for the same result after all 😉
Attaching to both
This is more of a fringe case, and won’t happen all too often, but it’s still good to be aware of this option!
Typically this will be applied if the majority of the traffic is identical in a subnet, but we require some fine grain control on a few virtual machines.
As with any technology there are a few limitations. At the moment you can have about 100 Network Security Groups, with as many as 200 rules per NSG. It’s possible to increase these limits by contacting MS Support. You will have to prove theres a genuine use case that requires more rules or groups though…
It’s also not possible to combine Endpoint ACL’s and Network Security Groups on Virtual Machines.
Azure Series Index
/EDITED FOR BAD KEYBOARD: Thank you Ricardo, for showing that even halfway across the world I can still count on you 🙂