Azure support for infrastructure as a service (IaaS) brings with it the ability to move virtual machines between your own data centre and the Azure public cloud. The ability to move workloads – be they properly coded cloud apps or traditional persistent virtual machines – is one of the core aspects of Microsoft's Cloud OS.

Today we can move virtual machines from our local data centre to a service provider to Azure and back again, but this has real-world security implications that must be considered.

Moving the virtual machines from A to B is remarkably simple. To add insult to injury, there are plenty of great walkthroughs sprinkled about the internet describing how to upload virtual hard disks to Azure, of Windows, use PowerShell to do a virtual machine replication for disaster recovery purpose, manage Azure virtual machines from inside Visual Studio, and even migrate VMware virtual machines into Azure.

Third-party services have naturally started to emerge to make the process easier and more closely geared to business needs. To contribute anything useful to the "how to" discussion would require either nerding very hard over one particular scenario or creating a small ebook covering the many ways available to get a virtual machine off your network and into Azure.

It is somewhat harder to find discussions about the security implications of Azure's IaaS offerings.

The walls have ears

It used to be that the only computer you could trust was one that wasn't connected to a network. Then came malware distributed by sneakernet, Van Eck phreaking (click here for a PDF of his 1985 paper, "Electromagnetic Radiation from Video Display Units: An Eavesdropping Risk?") and something called acoustic cryptanalysis that involves microphones and I am certain meets the legal definition of witchcraft.

Today, everything is online all the time and it is our job to deal with the situation.

Security in the cloud must be balanced against cost. Additionally, the hybrid cloud – the bridging of your corporate network and your off-premises cloud assets – brings its own considerations.

We like to move it, move it

Microsoft offers a couple of ways you can do this to get data from A to B, and it is a good starting point.

You can set up a site-to-site VPN, put an Active Directory domain controller in Azure, and treat the whole thing as though it were simply another site. This is the easiest method conceptually, as it does not differ much from traditional network models.

In doing this, you are replicating "eggshell computing" in a cloud environment: you stand up a bunch of virtual machines, isolated from the internet by ever-increasing quantities of static infrastructure.

That static infrastructure – be it a domain controller, a VPN server, a firewall or an IDS – has to exist as long as even one of your Azure IaaS virtual machines is active.

That is a minor headache when you have to buy a new widget every five years and put it at the edge of your data centre, but in the cloud you pay for what you provision, not what you use. You pay for every hour that every one of those static infrastructure virtual machines is active on Azure; even the VPNs are priced per connection-hour – only a few pennies short of per-hour pricing.

The other method of making sure data can flow between your cloudy virtual machines and your local infrastructure is getting your virtual machines to call home to your corporate network as needed.

This can be something as simple as a scenario where every virtual machine that spins up opens its own VPN connection back to your corporate network, or something more complex, such as programmatic RESTful communication. This involves a lot more effort perhaps, but is ultimately much more flexible.

More to the point, configuring each virtual machine to call home helps to create a break from the eggshell model of a hard perimeter and a soft vulnerable interior.

No matter how carefully you set it up , somebody with too much time on their hands and a few too many AWS bots will eventually stumble upon something in your virtual machine that prompts for a password

Each host in a cloud environment needs to be defended independently. It needs its own security infrastructure and its own monitoring, and all of this needs to be automated.

It makes financial sense to redesign your workloads to be as dynamic as possible, spinning up virtual machine instances only as needed and spinning them down or shrinking them whenever possible. That is the flexibility of the cloud.

This has security implications as well: a persistent workload is a persistent target. A dynamic workload is a heck of a lot harder to hit, dynamic and reactive security even more so.

Paranoia is the name of the game. No matter how carefully you set it up, somebody with too much time on their hands and a few too many AWS bots will eventually stumble upon something in your virtual machine that prompts for a password.

This could be a service that you are deliberately exposing to the outside world or it could be a service such as RDP that you would prefer to be only accessible by you.

Remember the password

How an attacker gains access to hidden services is where post-mortem happy fun time starts. But it happens.

Password hygiene is thus significantly more important in the cloud than in your on-premises network. Security through obscurity is sneered at, but your on-premises network is one among millions. Azure is a great big fat target, so creating a password policy and enforcing it is critical.

Host-based intrusion detection is an important concept. RDPGuard will detect attempts to brute-force RDP and ban the IPs of the culprits.

Another option is ts_block. The project hasn't received an update in two years, but it was written by Evan Anderson who has a reputation for writing good tools.

QaasWall is a far more active project which addresses more services than just RDP and comes a lot closer to the desired goal of a proper Fail2Ban for Windows.

Syspeace doesn't offer quite the same depth of coverage as QaasWall, but it is better geared towards automation and sharing of blacklists among your virtual machines. IPBan is also worthy of an honourable mention.

Having detected a market opportunity, Cyberarms has jumped into the void and provides a commercial tool openly marketed as Fail2Ban for Windows. I haven't had a chance to really start on it, but initial tests indicate that it does what it says on the tin.

Hide and seek

The traditional concept of security through obscurity is flawed. Take something that is relatively insecure, hide it and hope nobody finds it: that doesn't work so well when the bad guys have millions of robots scouring the internet every second of every day looking for something to exploit.

Still, obscurity is part of proper defence in depth. It is great to have intrusion detection systems, honeypots, tar pits and so forth, but how much better if your defences didn't actually have to be tested at all.

Obscurity is in fact now a default for Microsoft's IaaS virtual machines. Creation of a virtual machine through the portal does not allow you to use common passwords or many common names such as “administrator”.

Additionally, the portal generates a random port for RDP, instead of assigning the default 3389.

Combined with other positive steps such as encrypting the links between its data centres, Microsoft is doing a great deal towards making security the default. But we the customers must still play our part.

Firewalls on each host could be configured to respond only to a specific whitelist of IP addresses that correspond to your corporate network and perhaps designated disaster recovery sites.

You can create a gateway virtual machine that allows you to open a connection to virtual machines secured behind it via VPN, SSH, SSL or what have you. You can then use that virtual machine to proxy your management requests to virtual machines that are exposing only interfaces such as SSH or RDP to the internal private network.

If we want to get more paranoid than this – and oh, we do – we can automate obscurity by changing the ports for services like SSH and RDP on a regular basis. These could either be changed to rotate through a preset pattern at preset times, or set up to change the port to something random and send the information about what the ports were changed to back to your network.

As a backup, I tend to have a script somewhere that will run every 15 minutes or so and poll an XML file that simply contains a 1 or a 0. If the 0 turns into a 1, it means I broke the collection website and all the virtual machines should revert their management interfaces back to a preconfigured obscure port.

The art of self defence

Some of this might seem excessive but starting to think along these lines is just good practice. IPV4's days are numbered, and In an IPV6 world everything has a public IP address.

Defending each and every host has to become second nature, as we can't hide behind non-routable IP addresses forever. Any edge security system could be compromised and turned against the very virtual machines it was created to protect.

To take full advantage of the cloud, you will eventually want to have workloads in different data centres, some perhaps isolated for security reasons or to address privacy concerns.

What's more, in a cloud environment, the defences we mount need to be automated. To be economical, workloads have to be dynamic. That means their configuration, defence and obfuscation must be equally so.

Just as we must readjust our thinking to make dynamic workloads the default if we wish to realise the economies of the cloud, we need to give the same careful consideration to data movement in the hybrid cloud.

What data needs to move between your premises and Azure? What data needs to move between different Azure zones? Do the data connections need to be persistent or can they (like the virtual machines they service) be dynamic, automated and ultimately obfuscated?

Sysadmins the world over cheer IaaS offerings like those Microsoft is offering through Azure because they allow us to be mentally lazy. Assuming we can convince someone to foot the bill, we can carry on doing in the cloud what we are doing in our own data centres and not think too hard about it.

For a while, this is probably true. Microsoft has done a fine job of automating security, setting good defaults and carefully nudging sysadmins towards security best practice. ®