Many organizations begin their cloud journey with a single major cloud platform, such as AWS, Microsoft Azure or Google Cloud Platform. Eventually, many larger organizations began to realize that there are numerous potential limitations in a single-cloud model, including:
- Downtime concerns: If a cloud provider experiences a major issue, it could lead to a single point of failure that takes down network access and resources.
- Security and privacy: In any single cloud choice, there are numerous potential concerns with security and data privacy, leading to a need for encryption and review of the provider's internal controls.
- Vulnerability to attacks: If a single cloud provider environment is somehow exposed to vulnerabilities, this could have a ripple effect on anyone hosted there.
Other issues with a single-cloud model might include the limited control and flexibility in design, having a limited number of resources and additional platform dependencies. These issues and others are driving organizations to adopt a multi-cloud architecture that takes advantage of several different providers simultaneously. What happens to your security strategy when you move to a multi-cloud environment?
A multi-cloud security strategy
The short answer is that almost everything changes if you have been relying on traditional network platforms and cloud-native controls from providers. From a security perspective, different elements of controls may shift, with many of the cloud-native technologies proving difficult or unwieldy to manage.
One of the biggest issues organizations face when they invest heavily into a specific cloud provider environment is simple but potentially debilitating: vendor lock-in. When organizations place too much emphasis on the use of cloud-native security controls, like Security Groups in AWS or Network Security Groups in Azure, they may find significant limitations when shifting to a multi-cloud model. This is because the same types of access controls are needed in different provider environments.
To start for a multi-cloud security deployment, consider the following risk considerations:
- Separation of duties: Who is going to design and build each cloud provider infrastructure environment? In most organizations, a single team is responsible for all cloud architecture. However, in highly diverse organizations that are spread out geographically or by business unit, there may be distinct teams building each cloud. This can be challenging to oversee from a governance standpoint, and the traditional concept of separation of duties is changing dramatically. Similarly, who will be responsible for each cloud network's administration? Will a single team or multiple teams manage the ongoing environment once the cloud infrastructure is in place?
- Deployment tools and processes: What will deployment processes look like for each cloud? Ideally, a single deployment model for all infrastructure will be created, using a unified pipeline and tools. But this can be particularly challenging to implement, and not all controls will work easily across cloud environments.
- Network security: What are the network security controls available in each cloud environment? While there are some similarities in many of the leading IaaS provider controls, each offers unique services and capabilities, too. For example, AWS offers simple stateful Security Groups in addition to stateless, single-direction network access control lists to direct traffic between subnets and to/from instance workloads. Microsoft Azure, on the other hand, offers more traditional numbered firewall rule sets with its Network Security Groups. These aren't inherently compatible and require skills and tooling for both. At the same time, network risk profiles may be different for one cloud environment versus another. For example, AWS Security Groups start off in a default deny configuration, whereas Microsoft Network Security Groups allow some traffic within a subnet and the Azure environment to communicate.
- Security skills: Does the security team have skills for the different cloud environments? Do they understand the layering of security controls in each environment? Each environment will have different identity policies, logging and monitoring tools, configuration and patch management controls, and many more components.
Is moving to a multi-cloud strategy a good idea? From a security standpoint, it's neither good nor bad. Truthfully, it's just more work to prepare and look for security control options that can work across more than one environment, as well as learning the skills needed to implement controls and security processes that can function in each cloud environment as well.