5 Principles That Will Help You Run Securely in a Multi-Cloud Environment
After you've decided on a cloud provider like Google, Amazon, or Azure, you then have to make sure it's secure. But how? Read on to find out.
Join the DZone community and get the full member experience.Join For Free
You probably know AWS as the leading cloud platform provider. These days, however, many companies are using additional cloud providers, too. Most often they aren’t swapping one for another, but are choosing multiple. Different business requirements (such as managing risk and costs) may be better suited to different cloud vendors. Many vendors are likewise pricing their offerings competitively and continually adding new features. On the supply side of the equation, different cloud providers have different pricing models that companies may leverage in different ways.
There is nothing wrong with running a multi-cloud environment — and in fact, it may be a wise decision for your organization. But if you decide to go this route, you need to make sure you are taking appropriate security precautions. In this post, we’ll cover five principles to follow when you make the move to a multi-cloud environment. But first, let’s review the major players.
Three Major Public Cloud Platform Providers
Three major players dominate the public cloud platform world: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform. (And, of course, there is a host of smaller or niche players.)
AWS has been around the longest and has captured the largest share with 57% of the market running their apps on AWS. Microsoft has 34% of the market, and Google has 15% running apps on their cloud platform.
The article Public Cloud War: AWS vs Azure vs Google provides a helpful rundown of how the three giants compare when it comes to the following key areas:
Storage and databases
If you are trying to decide how much and which aspects of your environment to run in each of these services, this article should be helpful.
Now, let’s turn our attention to what it takes to secure your multi-cloud environment.
5 Principles for Running Securely in a Multi-Cloud Environment
1. Eliminate (or Control) ShadowOps
Has your entire organization agreed that it makes sense to run multiple cloud environments with different vendors? If the benefits of doing so outweigh the costs, then by all means, take advantage of the competition to reduce costs and get the features you need.
However, it is key to get on the same page before you get started. Otherwise, you will be like many organizations that wind up with several separate AWS accounts that are unconnected or have a number of different instances scattered across AWS, Azure, and Google. This can happen when DevOps team members make decisions for their unique use cases without looking at what is best for the organization as a whole.
As explained in ShadowOps Isn’t Just Bad DevOps, doing this can make your organization considerably less secure. Experts predict that, by 2020, a third of successful attacks experienced by enterprises will be directed at their shadow IT resources (see: 2017 Gartner Security & Risk Management Summit). So whether your organization decides to use one cloud provider or distribute infrastructure across several, make sure everyone has bought in and understands why this is the best approach for the organization. That will reduce ShadowOps-related issues and improve your overall security posture.
2. Strive for Visibility
Regardless of what cloud platform(s) you choose, you must ensure that you have as much visibility as possible across all your instances. This means that when you go to choose a cloud security solution, you want to select one that offers deep visibility, ideally starting at the workload layer.
Signature-based monitoring is simply not enough in the cloud. Instead, you should focus on increasing visibility through behavior-based monitoring. In other words, you want a solution that holds a magnifying glass to behaviors across all your instances and quickly detects anomalous behavior.
Your security solution should be able to:
Identify untrusted system modifications.
Catch threats with behavioral monitoring of users and processes.
Immediately detect anomalous users, processes, and file activity.
If you have visibility across all your cloud instances, then it becomes irrelevant whether you’re using AWS, Azure, Google, or a mix of the three. You will still be secure.
3. Understand Best Practices
Every platform comes with its own set of best practices. So if you are going to run infrastructure instances on multiple platforms, study up on best practices for each:
Azure lists (and updates) a series of articles that cover various cloud security topics in depth.
Google Cloud Platform shares a list of best practices.
Of course, there is a good amount of overlap, and some general rules apply, such as:
Know what is happening in your environment at all times.
Set up alerts (prioritize severity) that will notify you in case of out-of-policy behavior.
Meet and exceed compliance requirements.
Practice good hygiene (i.e., keep everything updated and patched).
Best practices shared by the cloud vendors themselves are a solid place to start because they know their technology better than anyone else, and they have a responsibility to educate and support their customers. Beyond that, we’ve written extensively about cloud security best practices, so be sure to review our blog for more tips.
4. Prioritize Automation
Humans make errors. Did you know that, through 2020, 95% of cloud security failures are expected to be the customer’s fault (2017 Gartner Security & Risk Management Summit)?
When it comes to security, human error introduces all kinds of risk. Relying on machines to automate tasks — especially those that are routine and repeatable — is key to ensuring that you don’t weaken your security posture, even while running multiple instances across several cloud vendors.
We often talk about how important it is to be secure by design. To accomplish this, you should focus on:
Updating your governance rules for the cloud.
Understanding the shared responsibility model (which we will cover below).
Adopting a continuous risk management approach.
Running in the cloud enables your DevOps teams to go faster. It enables continuous integration and continuous development cycles that can give you a real leg up on the competition. But it can also introduce risk, so leverage automation to ensure that security best practices are being managed efficiently and with minimal margin for error.
5. Understand the Shared Responsibility Model
Last but not least, make sure you understand the shared responsibility model. We have written before about its implications and the state of the model today. A whopping 79% of businesses experience risks that have actually translated into significant operational surprises in the past five years (2017 Gartner Security & Risk Management Summit). Much of this could be mitigated by following the shared responsibility model.
When you take advantage of the public cloud — whether AWS, Google Cloud, Azure, or a mix — it is your job to secure everything in the cloud. You can count on AWS, Google, and Microsoft to secure the cloud itself, but you must make sure that your applications, data, and other systems are fully secured in the cloud. For example, if someone logs into production without permissions and does something to put your organization at risk, you are responsible for that. So make sure you understand exactly where your responsibility begins and ends, and uphold it as well as you can.
Multi-Cloud for the Win
Having a host of cloud service providers is a sign of a healthy marketplace. While AWS has pulled ahead of the pack, it is a very good idea to explore your options and find out which public cloud (or which combination of them) is best for your organization to accomplish its specific objectives.
Keep security best practices at the forefront, take steps to prioritize visibility across your cloud environments, and you will be on your way to operating securely at speed and scale in the public cloud.
Opinions expressed by DZone contributors are their own.