(c)iStock.com/BrianAJackson

Even in mid-2016, very few who are serious about cloud computing will tell customers that out of the box public cloud services are as secure as their corporate data centres. At the same time no-one would suggest introducing mission critical applications and data into a brand new data centre environment without first planning and implementing proper physical, network, server, and application security controls.

Many organisations distrust moving corporate data and application assets into the public cloud. Loss of control of these assets is the most common reason stated; this is code for loss of control over the security aspects of the environment. To answer this, public cloud providers have developed some form of Shared Security Responsibility model.

For example, Amazon Web Services states that they are responsible for security of the physical plant as well as the separation between accounts or instances, while customers are responsible for building security into the solutions they deploy into their cloud account or instance. In other words, AWS is responsible for the security “of” the cloud and the customer is responsible for security “in” the cloud.

An often used solution that many organisations undertake in the separation of front end or presentation layers and the data aspects of a service into a hybrid cloud. This does not preclude any security deployment best practices that we will speak about but provides a level of comfort for organisations that their data is under their lock-and-key.  While hybrid cloud does not provide as much costreduction, flexibility or elasticity as “going public”, it does help the customer organisation feel more secure, in their decision.

Given the customer’s responsibility of security “in” the cloud, the customer needs to approach security around public cloud hosted instances in a similar (if not the same) manner that they approach corporate data centre hosted applications. Virtualised software components are available for everything from firewalls, to identity management, to intrusion detection, to virus checking, and many other aspects of the security landscape. If you wouldn’t deploy an application into your corporate data centre without a perimeter firewall, why would you deploy it into a cloud environment without the same technology?

When choosing a public cloud provider, it is prudent to look into the provider’s track record when it comes to security incidents. Again the provider is responsible for security “of” the cloud, so knocking a provider for a customer’s lack of proper security controls would be unfair. Most if not all public cloud providers publish data on their ability to protect their data centres and the overall cloud provisioning environment. So, do your homework.

Another aspect of the provider’s environment that may be useful in making an appropriate choice is evaluating the tools that the provider deploys to help a customer secure the environment. Once again using AWS as the example, they provide a list of security focused tools including:

• WAF: AWS WAF is a web application firewall that helps protect your web applications from common web exploits. WAF controls which traffic to allow or block to web applications by defining customisable web security rules.
• Security groups: A security group acts as a virtual firewall that controls the traffic for one or more instances. When an instance is launched it is associated with one or more security groups. Rules are added to each security group that allow traffic to or from its associated instances.
• Network access control lists (ACLs) – A network access control list (ACL) is an optional layer of security for your virtual private cloud (VPC) that acts as a firewall for controlling traffic in and out of one or more subnets.
• Virtual private gateway (VPG) – By default, instances launched into a virtual private cloud (VPC) can’t communicate with an external network. You can enable access to an external network from a VPC by attaching a virtual private gateway to the VPC, creating a custom route table, and updating your security group rules. IPSEC tunneling and connection to a Hardware VPN are supported.
• Inspector: An automated security assessment service that helps improve the security and compliance of applications.
• Identity and access management (IAM): Role based identity and access management for AWS account and logins.

Microsoft Azure provides many similar features to assist in securing environments in the cloud. One interesting option available from Microsoft is Azure Stack. Azure Stack is a hybrid cloud platform that allows an organisation to host a functional Azure deployment on premise, in their own corporate data centre. Not only can the on-premise environment be setup to interact (as expected) with Azure online resources, it is also managed from the same management console as the online environments.

Finally, when speaking of hybrid cloud environments, the customer has to prepare the corporate data centre environment properly with sufficient rigour to ensure security on their end. The corporate side of the VPN needs to be secured with the appropriate tools (Firewalls, IDS) and monitored as any other corporate environment.

Many organisations are struggling to balance the benefits of public cloud (lower costs, elasticity, scalability and flexibility) with concerns about security. While public cloud still does not provide the comfort level of hosting applications in the corporate data centre, it is evolving as an attractive option even for those who need a higher level of security. Hybrid cloud is one possible way to balance these needs if an organisation views the public cloud as an extension of the corporate data centre while planning for and implementing security “in” the cloud as if it were another data centre that they have access to.