Migration is a great time to re-think security

Let’s face it, most organizations trust everything inside the internal network, even though insider attacks easily account for more than 50% of reported attacks, and this is not going to get any better. And even if it isn’t an insider that is causing the problem, internal access by an attacker gives them free rein. Redesigning your network to limit inside access is a pain and creates restrictions that can cause issues, and with most companies now running 24/7, downtime is not an option.

One of the things I love about Azure (or any new environment for that matter) is that you are starting with a clean slate. It gives you a wonderful chance to re-think what you are doing, and how you want to continue doing it, in relation to accessing your servers and network security, and it all starts by limiting access to your servers.

The first simple step is to segregate your servers into more manageable groups. If you are wise, you have allotted a large pool of addresses to Azure, as this just makes things a lot easier now and in the long term. This gives you the chance to isolate the back ends from the user accessible front ends, by giving them their own subnets. Don’t be silly and give a whole class C to just 5 servers but do allow for expansion. Then you can use Application Security Groups (ASG’s) and Network Security Groups (NSG’s) on the subnets to control traffic to each group of servers, by only allowing required traffic. This doesn’t only apply to application servers, but also Domain Controllers, DNS servers, SCCM or other management servers, and anything else that can be grouped together.

For application servers, once you have isolated the front ends, now you can add Application Gateways (AG’s) with Web Application Firewalls (WAF’s) to further control access to the web front ends. This will not only protect your web servers from users, but also protect them from attacks that are already inside your network by protecting against common exploits and vulnerabilities. The great thing is that AG’s are easy to set up, can be used for multiple applications, and only need the DNS entry to be redirected to them for everything to continue to work.

Disaster Recovery (DR) is also a lot easier now your servers are in Azure. Azure Site Recovery (ASR) has been improved greatly in the last year, and now protecting an Azure VM is as simply as a couple of clicks in the portal and can be used to protect almost any server you have. While DR is not normally thought of, with it being this easy, it would be unwise to ignore it.

Now you have removed direct access to all your servers from every internal IP address, Administrators still need access. For Administrators you have some nice options now, from forcing Admins to use a jump box, to implementing Azure Just-in-Time (JiT) access to the VM’s, which forces them to request RDP and SSH access and limits this to a specified amount of time.

You have secured your servers in Azure, with very little effort and inconvenience. Users will not notice any difference in how they access the servers, and administrators must use secure practices to log into any of the servers. Changes are simple to implement, and you also have protection against a DR event. What could be better?

While this utopia seems to be overly simple, it really is not that complex to implement in Azure, providing you know how.