So you’ve decided to adopt a multi-cloud architecture. Good for you. Multi-cloud strategies can deliver a range of benefits, such as being able to negotiate better vendor terms, and increasingly, application availability.
If you have not also developed a plan for securing your multi-cloud applications and infrastructure, however, you’re at risk of undercutting your investment in a multi-cloud architecture.
To understand why, keep reading for tips on the special security challenges that arise in a multi-cloud environment, and how to address them.
What Makes Multi-Cloud Security Hard
A multi-cloud architecture, as the term implies, is any type of IT infrastructure that combines multiple clouds together. A multi-cloud architecture could entail combining private cloud with a public cloud, but it could also involve using multiple public clouds at once. (The latter definition tends to be what most people mean when they talk about multi-cloud architectures today, but it’s not the only way to do multi-cloud.)
By its nature, a multi-cloud architecture creates security challenges that would not exist if you were using just one cloud. They include:
- The inability to rely on one cloud vendor’s security tools. If you used only one cloud—such as only AWS, or only Azure—that cloud provider’s built-in monitoring and security auditing tools would support all of your infrastructure. But with multi-cloud, that obviously doesn’t work. AWS’s monitoring tools don’t support Azure, and vice versa.
- Multiple access-control configurations. The access-control tools provided by one cloud vendor also don’t work on another cloud vendor’s platform. This means that a multi-cloud strategy requires you to maintain and enforce multiple access-control configurations, one for each cloud.
- Complicated shared-responsibility requirements. Most public cloud vendors define shared-responsibility models that detail which management and security responsibilities they expect to handle, and which ones are the job of customers. Unfortunately, the shared-responsibility models of different cloud vendors are not identical. As a result, your responsibilities as an end-user on one cloud might be different from those on another cloud that you also use.
- More infrastructure “cracks.” Having more clouds means that you also have a higher potential for “cracks” to open up in your infrastructure. By cracks, I mean things like hidden security vulnerabilities or unsecured resources that you overlook. Avoiding cracks is hard enough for a sizeable organization if it only has one cloud. When you add more clouds, the cracks become even harder to find and address.
- More to manage. When you have multiple clouds, you have more to monitor and manage. In this sense, the trend toward multi-cloud architectures is similar to the rise of microservices and containers, which also involve many more “moving parts” than earlier infrastructure technologies. The trade-off for this added complexity is greater reliability and agility, of course, so it’s well worth the trouble for most organizations. Still, the fact remains that managing more clouds—from both an IT Ops and a security perspective—is harder than managing only one cloud.
Multi-Cloud Security Best Practices
What’s an organization to do when facing these multi-cloud security challenges? The answer is obviously not to avoid a multi-cloud architecture; that would mean depriving yourself of the distinct cost-saving and reliability advantages that multi-cloud architectures can deliver.
Instead, IT teams who manage multi-cloud architectures must design and adopt practices that can help them to keep their clouds secure in order to protect their investments in a multi-cloud infrastructure. These practices include:
- Embracing multi-cloud security tools. While the security monitoring and access-control tools that your cloud provider offers to you may be useful in some circumstances, a cloud-native architecture means that you will typically need to make greater use of third-party, cloud-agnostic security tools that can support whichever combination of clouds you use.
- Automate, automate, automate. The more you automate, the more you decrease your chances of letting something fall through the cracks due to human oversight. Automation is a powerful tool for any modern IT workload, but it’s especially crucial for avoiding security mistakes when you have a complex multi-cloud architecture.
- Least privilege access control by default. The safest approach to access control in a multi-cloud architecture is to lock down access to the bare minimum by default on each cloud that you use, and work up from there by granting additional permissions to the accounts that need them. Combine this with SSO so users have a single, strongly protected identity to use to across your cloud deployments.
- Consider security first and foremost when choosing which clouds to use. While all cloud platforms, public and private, have security risks, some clouds may be more secure than others for the specific types of workloads you want to deploy. When you are choosing which clouds to use, evaluate how secure the candidates are for your needs. Then, weigh that assessment alongside other factors (such as cost and reliability), as you decide which clouds to adopt.
- Don’t be afraid to switch clouds. Keep in mind, too, that you can always swap out one cloud with another one if it offers better security. Part of the advantage of a multi-cloud architecture is that it helps free you from being locked into a particular cloud vendor. Leverage this freedom to bolster cloud security when appropriate.
Multi-cloud architectures can be a great resource for helping to build cost-efficient, agile infrastructures. But no multi-cloud strategy is complete if it does not address the special security challenges that multi-cloud brings. The challenges are eminently addressable, but only if you factor them into your multi-cloud strategy from the start and keep them constantly in mind as you update your multi-cloud architecture.
- Application Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Istio Visualization, Security, and Compliance Checks with TwistlockRead the Blog
Protecting Serverless Functions at Runtime: Serverless Defender v2Read the Blog
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog