Everybody and their dog nowadays are trying to move their IT infrastructure into the cloud. The benefits are pretty obvious: less hardware to maintain, more predictable costs, greater agility, more scalability, and so on. But is hosting your server workloads and applications in the cloud a good idea from the point of view of security? Is it safe to keep all your IT assets and sensitive business data in the cloud? After all, the cloud you’re using is nothing more or less than a collection of geographically dispersed datacenters owned and run by someone else.
What’s more, cloud vendors are usually at pains to tell you that they can definitely keep your configurations and data safe and secure. “Just trust us” is their mantra. Which reminds me of what Tom Cruise (Roy) told Cameron Diaz (June) in the movie “Knight and Day,” which I have to confess is one of my all-time favorite movies:
Roy: They’ll probably identify themselves as federal agents, and they’ll DIP you.
June: Dip me? In what?
Roy: Dis-Information Protocol. They’ll tell you a story about me. About how I’m mentally unstable, paranoid. How I’m violent and dangerous, and it’ll all sound very convincing.
June: I’m already convinced.
Roy: There’s a few common DIP keywords to listen for. Reassuring words. Words like, “stabilize,” “secure,” “safe.” If they say these words, particularly with repetition…
June: Okay.
Roy: …it means they’re going to kill you.
In a similar way, when I’m told by a cloud vendor that my IT infrastructure will be “safe” and “secure” in their cloud and that moving it there can help me “stabilize” my business, the first thought that often comes to my mind is “they’re going to kill me.”
So the question is this: How can I avoid getting killed if I move my infrastructure into the cloud? Or am I just being mentally unstable and paranoid?
Think on-premises
The best place to begin thinking about how to architect security for your cloud-based infrastructure is to imagine it being located on-premises instead of in the cloud. In other words, many of the same principles you would follow to secure a traditional on-premises infrastructure are just as valid if you’re hosting virtual machines or containerized workloads in Amazon Web Services, Microsoft Azure, or some other vendor’s public cloud services.
In Microsoft Azure for example, if your virtual network is large, then segmenting it into subnets based on logical tiers and then using network security groups (NSGs) to create allow/deny rules for managing internal traffic on your virtual network is a good idea. NSGs act like stateful packet inspection devices and can help you control which packets can be routed between your subnets based on the source and destination IP address and port of the packet together with the OSI layer 4 protocol for the packet.
You can also add some additional security to your virtual network by deploying a virtual network security appliance like the Barracuda Web Application Firewall or the Sophos XG Firewall on Azure, but be aware that adding such virtual appliances generally requires configuring user defined routes (UDRs) to your virtual network and enabling IP forwarding on the virtual machine hosting the appliance.
Just like when you want to connect your on-premises network to the Internet, creating a perimeter network or DMZ is also important for your virtual network to secure your cloud assets when they are accessed from across the Internet. In fact, most of the best practices associated with DMZ design for on-premises networks carry right over into the ethereal world of cloud computing.
Enable cross-premises connectivity
If you’re currently in the process of migrating your company’s infrastructure into the cloud, you probably have some form of hybrid infrastructure at the moment that is part cloud and part on-premises. Many companies even choose to remain there for reasons ranging from internal company politics to transnational compliance requirements. Regardless of whether you’re going to remain in the hybrid zone or not, it’s critical that you have secure connectivity between your on-premises and cloud infrastructures.
Again considering Microsoft Azure cloud services, one way of implementing secure cross-premises connectivity is to use the site-to-site VPN feature of Azure, which uses IPsec tunnel mode to create an encrypted tunnel over the Internet between your on-premises and cloud infrastructures. The bandwidth of this feature is limited, however, to about 200Mbps, so if you need greater bandwidth connecting your infrastructures, you’ll likely want to go the dedicated WAN link route and make use of Azure ExpressRoute.
Kill off RDP
Remote Desktop Protocol (RDP) is a wonderful way of connecting to remote Windows servers (whether physical or virtual) so you can manage them as if you were sitting in front of them at the console. And it’s easy, of course, to RDP directly over the Internet into your virtual machines running in Microsoft Azure so you can configure, manage, and maintain them to keep the services and workloads running on them in top-notch performance.
Unfortunately, RDP (and SSH as well) can be considered a security vulnerability when they’re enabled on virtual machines hosted in the cloud since an attacker could try a brute-force attack to try to gain access to your machines. If you have a cross-premises connectivity solution like site-to-site VPN or Azure ExpressRoute set up, however, you don’t need to have direct RDP access over the Internet enabled for your Azure virtual network. Instead, you can securely RDP your virtual machines through your site-to-site VPN or dedicated WAN link.
And even if you don’t have one of these cross-premises connectivity solutions implemented, you can still create a point-to-site VPN in Azure that uses two-step authentication to doubly protect your virtual machines from brute-force attacks against RDP. In a point-to-site VPN scenario, first authentication is done when the VPN connection to the remote machine is authorized; second authentication then occurs in order to authorize the creation of the RDP session. The same is true for SSH.
And the answer is …
There’s a lot more I could talk about with regard to keeping your cloud infrastructure safe and secure, but you’re probably wondering why I haven’t yet answered the question I posed earlier in this article, namely: Am I being paranoid by worrying that I’ll get killed if I move my company’s infrastructure into the cloud? The answer, of course, is “yes,” I’m being paranoid — and you should be, too! With the rapid pace of technological change being fomented by cloud computing, new technologies and features are being introduced well before the potential impact on security of these features have been adequately explored. And with larger cloud providers, many of the changes they make in the back end of things are not publicly announced or properly documented. All the more reason to adhere to well-known best practices for securing networks of any form, both on-premises and in the cloud.
Photo credit: FreeRange Stock
