We say “Yes!” to public cloud platforms. To understand our position, we will elaborate around the risks associated. We will address how to mitigate risks and take advantage of the benefits provided by these platforms. Finally, we will explain how we work with public cloud in Turbulent Flux.
Nowadays, a lot of companies choose to take advantage of the cost effectiveness, flexibility and ease of use offered by public cloud platforms. The questions are whether it is safe to put your data on public cloud and if the platforms are secure. How is your data stored? Who can access your data? Are there any laws or regulations that may allow a third party to access your data?
Is public cloud as attractive as it seems?
Today’s public cloud platforms seem highly appealing. With a few clicks you set up your account, and at a very low entry fee you are ready to get started. Maintenance fees of public clouds are substantially lower than for a standard infrastructure. While an added cost of the cloud services counterbalances the reduction in maintenance costs to some extent, this is vastly outweighed by the benefit that you can focus on the solution development instead of infrastructure maintenance.
Another advantage is that public cloud is truly flexible. For example, if an online marketplace plans a special sale that can lead to lots of traffic and orders placed in a very short time, they can use auto-scaling to dynamically resize the infrastructure and ensure that the solution can handle the added load.
The benefits above aside, there are still a few things you must be aware of when you use public cloud platforms. Firstly, you must cater to the security of your solution and not just trust your public cloud platform provider in terms of security. Irrespective of their investments into security, you can never say that a platform is hacker proof since infrastructures can never eliminate all security threats.
Secondly, you must pay attention to the public cloud provider’s ability to ensure availability to your data. This is generally not a challenge for big public providers, but if you choose a smaller provider you must evaluate this. Thus, you should pay attention to the reliability of the service as well as its ability to scale up when your need increases.
Thirdly, you must understand how your data is secured inside the platform. As a minimum, your data should be encrypted. This ensures that your data cannot be easily accessed in case of an intrusion.
Lastly, you must be aware of the legislation to which your provider is subjected. Here, it is important to notice that in addition to the regulations that apply in the country where your services are hosted, you must also consider legislation in the country where the service provider’s headquarter is located. For example, in 2011 Microsoft’s Managing Director in UK, Gordon Frazer, concluded that US headquartered companies must comply with US law even for data centers located outside US [1]. Thus, being a company headquartered in the US, the Patriot Act [2] and Cloud Act [3] applied also for solutions hosted in a UK data center.
How to take advantage of a public cloud platform
One way to address the challenges above is to take the zero-trust principle as a starting point and transfer it to a cloud architecture. To explain this term first, “zero trust provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised” [4].
From a cloud point of view, this means that we must design our cloud solution in a way that no one part trusts any other part of the solution. This may seem natural for components provided by a third-party, but equally well applies to your own components since they can be compromised (zero-compromising risk does not exist).
One should therefore be alert to these guiding principles:
Firstly, encrypt any communication between critical components in the solution. A critical component is any component that handles sensitive data.
Secondly, grant access to data and services only to those who require access. This avoids unintentional or unauthorized access as well as reduces the attack surface [5].
Thirdly, isolate components, i.e., do not expose components to the network and external access unless necessary. For example, your database does not need to be directly accessible from the Internet. This further limits the attack surface for an intruder.
Finally, you must try to make your solution as redundant as possible to avoid performance bottlenecks and reduce the risk of downtime.
Applying data security guidelines
There are different ways to secure your solution, and the below outlines some basic security frameworks that you can apply.
Securing your data
By default, public cloud providers encrypt your data with an encryption key that they hold. This does not ensure data privacy, which can however be achieved by additional encryption.
1) Customer-managed encryption. This allows you to encrypt your data with encryption and decryption keys provided and managed by the cloud platform. The drawback is that the cloud provider holds the decryption keys.
2) Customer-supplied encryption. This is similar to the previous solution, but there is an important difference; the public cloud platform only stores the encryption key. This means that the cloud platform can encrypt data but it cannot decrypt since the customer holds and manages the decryption keys.
3) Client-side encryption means that the customer solution handles all encryption/decryption. The cloud platform does not store any keys. The drawback is that you need to handle the storage of encryption and decryption keys yourself.
For Turbulent Flux the best trade-off is to use customer-supplied encryption keys for components which handle non-sensitive private data; customer-managed encryption for components which handle public information; and client-side encryption for components which are critical, and handle secret or sensitive data.
Securing access and communication
To secure all communication between components within your solution, you can start by applying a few rules. The first is that all communication and requests passed between components use an encrypted protocol, for example Secure Socket Layer for internal and external API requests.
The second option is internal authentication between components. This means that a component must be authenticated to communicate with another one. This also means that you more easily can stop an intrusion if one identifier is compromised.
Finally, you can apply isolation and limiting rules to reduce the attack surface. This means that you isolate critical services which do not need to be publicly exposed. This also means that you can define rules to publicly expose only what needs to be exposed.
To us, the best option is to use all these options in combination.
Ensuring redundancy
To ensure that your data is always accessible and to ensure good availability of your solution, you can use the ability of your cloud provider to replicate data in multiple locations. For example, you can configure your solution to reside on multiple locations. If there is major downtime on your primary location, the other locations will ensure that your service remains accessible.
You can also consider to apply the “Chaos of Engineering” [6] philosophy to your infrastructure to ensure that it is resilient to component failure. This randomly mimics the failure of a component in the production environment to ensure that your solution will remain available even if there is a failure.
Public Cloud does not mean Unsecure!
At Turbulent Flux, we put security first when we develop our solutions for public cloud platforms. For us, it is important that you feel that you entrust us with your data and that our solutions are available without disruption. The above offers a flavor of the considerations we make to ensure secure and available solutions on Public Cloud in order to eliminate risks for our clients.
[1] https://www.zdnet.com/article/microsoft-admits-patriot-act-can-access-eu-based-cloud-data/
[2] https://www.govinfo.gov/content/pkg/PLAW-107publ56/pdf/PLAW-107publ56.pdf
[3] https://en.wikipedia.org/wiki/CLOUD_Act & https://www.govinfo.gov/content/pkg/BILLS-115hr1625enr/pdf/BILLS-115hr1625enr.pdf
[4] https://doi.org/10.6028/NIST.SP.800-207
[5] Attack surface: the total number of points, or vectors, through which an attacker can try to enter an environment. Source : https://www.wired.com/2017/03/hacker-lexicon-attack-surface/
[6] https://principlesofchaos.org/
