Moving to the cloud is “easy”; Managing it is another ordeal.
I’m going to start with a disclaimer; This post focuses on achieving governance and security in Azure; This doesn’t mean that what I’m going to write here cannot apply to AWS or Google, they have other technologies that can help you achieve full governance;
Do you deploy your apps in containers? Do you scan them for security vulnerabilities? No? You should.
Containers are all the rave this year and will continue in the following years; The problem that we’re going to face really soon (honeymoon effect) with the boom of containers is that security is still important even here.
What? Security around containers? “Containers are immutable and secure and don’t have moving parts and…”
Compared to a regular VM, yes containers are much more secure because they have a lower footprint but that doesn’t mean you shouldn’t care about security. You can hack a container as simple as a simple VM. You’re running Apache, NGINX, Node? If you’re running old versions that have vulnerabilities, guess what, they can be exploited 🙂
Security is not something to kid about and when it comes to cloud, you have to be very through when you’re deploying your cloud infrastructure. Which means that you are still required to do defense in depth, use anti-malware systems, configure extended monitoring, logging and reporting mechanisms. When you’re going to the cloud, you have to be aware of the Shared Responsibility Matrix which applies to any cloud provider.
As you can see in the image above, you as a customer still have a responsibility to secure your cloud environment. So those skills you’ve developed while working on-premises will still be of value in the cloud.
The subject for today’s topic is managing Network Security Groups using a feature in Azure, called Application Security Groups.
What are they?
Application Security Groups are a mechanism to group virtual machines that reside in the same virtual network and apply Network Security Groups to them.
The way you deployed NSGs in Azure subscription was that you would assign them to a network interface or a subnet and then configure them in a granular manner, based on the deployment type. The reality was that it’s utopic to do this cleanly and it gets messy after a couple of months. So ASGs came to the rescue where it helped you group a set of VMs based on roles like Web, DB, Middleware etc. and apply NSG Allow / Deny rules on them.
By using an ASG, you simply your management overhead by just adding the VMs that you create in those groups and automatically you get the security policies applied from your NSG.
Creating / using Application Security Groups is easy. Go to the Azure Portal -> Create a resource -> Type in Application Security Group and press create.
Or you can simply use Powershell
#PS Example for creating Application Security Groups.
$testAsg = New-AzureRmApplicationSecurityGroup -ResourceGroupName asgTest -Name testAsg -Location westeurope
After you’ve created the ASG, the next thing that you need to do is to assign it to some VMs, which can be done via the Portal or PS.
#PS Example for attaching ASGs
$Nic = Get-AzureRmNetworkInterface -Name test134 -ResourceGroupName asgtest
$Nic.IpConfigurations.ApplicationSecurityGroups = $testAsg
Set-AzureRmNetworkInterface -NetworkInterface $Nic
Next step is to add or modify your inbound / outbound rules to use those new ASGs you’ve created. Doing that is very simple and you can also do it via the portal or CLI.
As you can see, it’s pretty easy to secure your VMs, and considering that it can become a pain to manage the NSGs even for simple deployments. I’m not even talking about very complex ARM deployments which deploy tens of VMs and link them together 🙂