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.