Stay on the cutting edge. Subscribe to our blog.
Network security in a multi-cloud environment
What happens to your networking strategy when you move to a multi-cloud environment? The short answer is: almost everything, especially if you have been relying on traditional network tools. From a networking perspective, to ensure applications and services can communicate as intended and do so securely, the tools and process for managing a multi-cloud environment need to be cloud-ready. The cloud-native controls included in providers’ offerings may seem like the easiest solution.
Cloud-native controls are great baselines, but from a security perspective they may fall short of your desired state or prove difficult or unwieldy to manage and monitor. Not to mention, if your multi-cloud strategy includes various providers and you’re reliant on cloud-native networking controls like Security Groups or Network Security Groups, you’ll end up dealing with disparate sets of controls that don’t necessarily translate across environments. This can become a debilitating concern and leads some organizations back toward a single-cloud deployment, which is not always the right choice.
In a multi-cloud model, it’s best to implement the same types of access controls in different provider environments. Doing so significantly reduces complexity and provides uniform visibility and manageability across environments.
To start planning for a multi-cloud network deployment, consider the following:
- Who is going to design and build each cloud provider network 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.
- Who will be responsible for each cloud network’s administration? Similar to the point above, will a single team or multiple teams manage the ongoing environment once the cloud infrastructure is in place?
- What will deployment processes be for each cloud? Ideally, a single deployment model for all infrastructure will be created using a unified pipeline and tools.
- What network security controls are available in each cloud environment? While there are some similarities between many of the leading IaaS provider controls, each offers unique services and capabilities, too. For example, Amazon Web Services offers simple stateful Security Groups and stateless, single direction Network Access Control Lists to control traffic between subnets and to/from instance workloads. Microsoft Azure, on the other hand, offers more traditional numbered firewall rule sets with their Network Security Groups.
- Are the risk profiles different for one cloud environment vs. another? For example, Amazon Security Groups start off in a “default deny” configuration, whereas Microsoft Network Security Groups allow some traffic to communicate within a subnet and the Azure environment.
- Does the security team have the necessary skills to manage different cloud environments, and do they understand the layering of network controls in each environment?
All of these areas need consideration, of course, but one of the most critical components of a successful multi-cloud deployment is centralization.
Centralized control for your multi-cloud model
With a multi-cloud network architecture, network and security teams are potentially facing a fragmented set of security access controls and monitoring tools that could be difficult to manage if designed and implemented uniquely in each provider environment. As such, some cloud operations teams look to multi-cloud brokers to help with centralizing and integrating all cloud management. However, enterprise network and security teams can also select a single third-party platform that can integrate across all environments. Doing so allows for centralized control of network security policy and access management regardless of the underlying cloud infrastructure.
For public cloud in particular, a more advanced strategy for implementing strong, centralized network security is zero trust microsegmentation. If you have a large presence in Amazon Web Services, Microsoft Azure, or Google Cloud Platform, for example, you are likely already using basic microsegmentation technologies:
- In AWS, this is implemented via Security Groups
- In Azure, this is implemented with Network Security Groups (NSGs)
- In GCP, this is implemented with Compute Engine firewall rules
The above microsegmentation tools are cloud-native and often facilitate access controls and isolation for virtual machine instances and other assets you’ve deployed in the particular cloud service environment you’re using. These tools are perfectly fine for simple use cases, but they have several limitations that should be considered. First, these are explicit to each cloud provider and could lead to more dependence on the provider than you want. Additionally, these methods of implementing microsegmentation only work in the public cloud and won’t be applicable to any on-premises assets you have in a hybrid cloud network architecture; ideally, you can make use of a single microsegmentation platform that works across all the environments you operate in. Finally, these cloud-specific controls may not scale well into hundreds and thousands of distinct assets with unique rules and policies that have to be juggled across numerous environments, and providers often have hard limits on the number of rules and access control groups you can create.
In short, provider-based controls have their place but should be considered a starting point or augmentation technique to a more central and capable network control platform.
The need for network visibility
Aside from cloud-native network controls, one of the most critical needs for network and security teams building workloads in multiple cloud environments is enhanced visibility and insight into workload behavior and applications. It’s this visibility that largely forms the basis of a true zero trust model of microsegmentation. No cloud-specific tools provide this level of introspection and dynamic policy evaluation today, meaning that third-party tools will be needed to 1) accurately map out what types of application traffic are being seen and 2) apply a centralized policy to workloads communicating across multi-cloud and hybrid environments. For dynamic, mobile workloads, operations teams need a much more granular and nuanced access control model than simple layer 3 and 4 firewall rules — application behavior and workload alignment and affinity are vastly more important in the modern multi-cloud network.
Choosing your cloud security strategy wisely
To be sure, security teams have more options available for implementing a defense-in-depth network control architecture in multiple clouds (as well as on-premises environments) than ever before. However, not every tool or strategy is necessary to run an effective security program. Instead, security and networking teams should focus on:
- Centralization: Tools that can capably be implemented centrally for policy creation and overall management. The easier to manage operationally, the more successful the network design will be.
- Multi-layered microsegmentation: Traditional firewalls still have their place for enabling network connectivity between on-premises and cloud environments and may provide intrusion prevention and other necessary controls. However, they’re not enough to prevent malicious east-west traffic. Instead, security teams should implement a multi-layered microsegmentation approach that works uniformly across all operating environments.
- Visibility: For large cloud deployments, a base implementation of some cloud provider-native controls may prove valuable, but a multi-cloud design with numerous assets will benefit from deeper application visibility that is enforced similarly in all cloud environments. This will result in centralized monitoring and reporting across environments, as well.