Cloud computing, with its promise of reduced CAPEX and OPEX, presents a compelling business case. In IaaS, computation resources are rented from a cloud service provider (CSP). There is no server hardware or software to purchase and maintain, and organizations benefit from reduced IT expenses and improved flexibility. Enterprises have fewer IT headaches to deal with and can focus on their core business.
However, the possibility of security breaches has made the public cloud model risky. Here’s the problem: If I can access my virtual servers remotely, anyone else can access them, too.
Threats include denial-of-service (DoS) attacks, whereby a bombardment of messages takes down the virtual server; data theft, whereby sensitive data is accessed through a security breach; and hijacking, whereby intruders use your virtual server to attack third parties.
“Now, wait a minute,” one might say. “I’ve signed on with an industry-leading public cloud provider. I’m sure they are aware of the threats and will provide the required solution, right?”
Well, partially right. Public cloud providers are well aware of data security threats, and can protect you against some of them, but they wish to make it clear to you that security is a shared responsibility.
Here is what Amazon says:
Because you’re building systems on top of the AWS cloud infrastructure, the security responsibilities will be shared: AWS has secured the underlying infrastructure and you must secure anything you put on the infrastructure. This includes your AWS EC2 instances and anything you install on them, any accounts that access your instances, the security group that allows outside access to your instances, the VPC subnet… etc.
And here is what Rackspace says:
In addition to the foregoing obligations, you acknowledge that you are solely responsible for taking steps to maintain appropriate security, protection and backup of customer data.
“Public cloud providers… wish to make it clear to you that security is a shared responsibility”
There it is – leading IaaS providers have made it clear in their terms of service that responsibility for public cloud deployment is a shared one.
So what can be done to mitigate the security risks that are inherent in public cloud computing?
Firewalls
Firewalls enable the filtering of data traffic using rules that define which data flows are allowed and which are denied (discarded). A server-based (aka host-based) firewall is software working on the VM (server) operating system level. Since the OS layer and above are the responsibility of the cloud consumer, off-the-shelf IaaS offerings do not provide this functionality.
Hypervisor-based firewalls are implemented at the hypervisor (virtualization) level that is controlled by the cloud provider. Some cloud providers offer a functionality that can be controlled by the IaaS consumers using the service GUI and/or APIs. Note that some hypervisor-based firewalls only control incoming traffic (while a complete firewall would control also outgoing traffic). Examples of hypervisor-based firewalls are the AWS Security Groups and Google’s GCE tags.
The main shortcomings of these firewall mechanisms are that they do not protect against IP spoofing (‘stealing’ of IP addresses) and they are not identity-aware, ie they cannot tell who is behind the IP data flow.
Virtual Private Clouds
A virtual private cloud (VPC) is a pool of compute resources (usually VMs), allocated from a public cloud environment, that are logically separated from the rest of the shared environment of the public cloud. Logical isolation is very commonly achieved by the cloud provider allocating a dedicated VLAN for the VPC, thus disabling any internal data center access to those VMs from VMs outside the VPC (VLAN).
Usually, VMs inside a VPC can be launched only with a private IP address and thus are inaccessible from the internet. Examples for VPCs are AWS VPC, Rackspace’s Cloud Networks and GCE (the default behavior of GCE is VPC-like).
VPCs are an important component in securing your IaaS deployment. VPCs, however, do not solve the issue of how to ensure secure access to the VPC from the outside world.
Centralized Identity-Based Access
In identity-based access the identity of a user attempting to access cloud resources is first authenticated (eg with a username and password) and then granted access upon successful authentication. A best practice for implementing centralized identity-based access is using a VPN gateway.
In a VPC setting, a VPN gateway can be the only server with a public IP address, authenticating remote users and routing their data flows to and from the isolated VPC. Using VPN to access the cloud provides a strong association between identity and IP address, thus protecting against IP spoofing. Other benefits of a VPN gateway are the encryption of data in transit (to and from the cloud) and the ability to enforce access rights and firewall rules (by the VPN gateway) on all user traffic.
Central identity-based access using VPN is not normally offered as part of the off-the-shelf infrastructure services.
About the Author
Amit Cohen is co-founder and CEO of FortyCloud, which was founded to promote the secure migration of enterprises to the public cloud