enabling segmentation for multicloud enterprises

A Case Study for Security and Flexibility in Multi-cloud Environments

Most organizations today opt for a multi-cloud setup when migrating to the cloud. “In fact, most enterprise adopters of public cloud services use multiple providers. This is known as multicloud computing, a subset of the broader term hybrid cloud computing. In a recent Gartner survey of public cloud users, 81% of respondents said they are working with two or more providers. Gartner comments that “most organizations adopt a multicloud strategy out of a desire to avoid vendor lock-in or to take advantage of best-of-breed solutions”.

When considering segmentation solutions for the cloud, avoiding vendor lock-in is equally important, especially considering security concerns.

Let’s consider the following example, following up on an experiment that was performed by one of our customers. As we discussed in the previous posts in the series, the customer created a simulation of multiple applications running in Azure and AWS. For the specific setup in Azure please consider the first and second posts in this series.

Understanding the Experiment

 

Phase 1 – Simulate an application migration between cloud providers:

The customer set up various applications in Azure. One of these is the CMS application. NSGs and ASGs have been set up for CMS, using a combination of allow and deny rules.

The customer attempted to migrate CMS from Azure to AWS. After the relevant application components were set up in AWS, the customer attempted to migrate the policies from Azure Security Groups to AWS Security Groups and its Access Control List. In order for the policies to migrate with the application, the deny rules in Azure Security Groups had to be translated into allow rules for all other traffic in AWS security groups or to network layer deny rules in AWS access control lists (ACLs).

Important differences between AWS security groups and ACLs:

  1. Security groups – security groups are applied at the EC2 level and are tied to an asset, not an IP. They only enable whitelisting traffic and are stateful. This is the first layer of defense, thus traffic must be allowed by Security Groups to then be analyzed by an ACL.
  2. ACLs – access control lists are applied at the VPC level, thus are directly tied to IPs. They support both allow and deny rules, but as they are tied to specific IPs, they do not support blocking by application context. They are not stateful and thus are not valid for compliance requirements.
  3. AWS security groups do not support blacklisting functionalities and only enable whitelisting, while AWS ACLs support both deny and allow rules, but are tied to an IP address within a VPC in AWS, enabling blocking only static IPs or a whole subnet.

Given the differences between security groups and ACLs (see sidebar), migrating the CMS application from Azure to AWS alongside the policies, required an employee to evaluate each Azure rule, and translate it to relevant rules in AWS Security Groups and ACLs. This unexpectedly set back the migration tests and simulation.

This is just one example. Each major public cloud provider provides their own tools for policy management. Working with multiple cloud native tools requires a lot of time and resources, and results in a less secure policy and added inflexibility. The more hybrid your environment, and the more you depend on native tools, the more tools you will end up using. Each tool requires an expert, someone who knows how to use it and can overcome its limitations. You will need to have security experts for each cloud provider you choose to use, as each cloud provider has a completely different solution with it’s own limitations. An example of one such limitation that all cloud provider native segmentation tools share is that cloud-based security groups only provide L4 policy control, and so additional tools will be required to secure your application layer.

Guardicore Provides a Single Pane of Glass for Segmentation Rules

When using Guardicore, each rule is applied on all workloads: virtual machines, public clouds (AWS, Azure, GCP…), bare-metal, and container systems. Rules follow workloads and applications when migrating to/between clouds or from on-premises to the cloud. Security teams can work with a single tool instead of multiple solutions to build a single, secure policy which saves time and resources, and ensure consistency across a heterogeneous environment.
Guardicore therefore enables migrating workloads with no security concerns. Policies will migrate with the workloads wherever they go. All you will need to take into account in your decision of workload migration is your cloud provider’s offering.

Our customer used Guardicore to create the CMS application policies, adding an additional layer 7 security with rules at process level, enhancing the Layer 4 controls from the native cloud provider. To migrate CMS from Azure to AWS seamlessly, policies were no longer a concern. Guardicore Centra policies follow the application wherever it goes. As policies are decoupled from the underlying infrastructure, and are created based on labels. The policies in Guardicore followed the workloads from Azure to AWS with no changes necessary.

Phase 2 – Create policies for cross-cloud application dependencies

The customer experiment setup in AWS included an Accounting application in the London, UK region, that periodically needed to access data from the Billing application databases. The billing application was set up in Azure.

The Accounting application had 2 instances, one in the production environment and another in the development environment. The goal was for only the Accounting application in production to have access to the Billing application.

In a recent Gartner analysis Infrastructure Monitoring With the Native Tools of AWS, Google Cloud Platform and Microsoft Azure, Gartner mentions that “Providers’ native tools do not offer full support for other providers’ clouds, which can limit their usability in multicloud environments and drive the need for third-party solutions.” One such limitation was encountered by our customer.

Azure and AWS Security Groups or ACLs enable controlling cross-cloud traffic based only on the public IPs of the cloud providers. One must allow the whole IP region range of one cloud provider to communicate with another in order for two applications to communicate cross-cloud.
No external IP can be statically set for a server in Azure or AWS. Thus without introducing a third-party solution, there is no assurance that traffic is coming from a specific application in Azure when talking to a specific application in AWS and vice versa.

As public IPs are dynamically assigned to workloads within both Azure and AWS, our customer had to permit the whole IP range of the AWS London, UK region to communicate with the Azure environment, with no application context, and no control, introducing risk. Moreover, there was no way to prevent the Accounting application in the development environment from creating such a connection, without introducing an ACL in AWS to block all communication from that application instance to the Azure range. This would be problematic and restrictive, for example if the dev app had dependencies on another application in Azure.

Guardicore Makes Multi-cloud Policy Management Simple

As we have already discussed, policies in Guardicore are decoupled from the underlying infrastructure. The customer created policies based on Environment and Application labels with no dependency on the underlying cloud provider hosting the applications or on the application’s private or public IPs. This enabled easy policy management, blocking the Accounting application in the Development environment on AWS while allowing the Production application instance access to the Billing application in Azure. Furthermore, this gave our customer ultimate flexibility and the opportunity for future application migration seamlessly between cloud providers.

Guardicore provided a single pane of glass for multi-cloud segmentation rules. Each rule was applied on all relevant workloads regardless of the underlying infrastructure. Security teams were able to work with a single tool instead of managing multiple silos.

The same concept can be introduced for controlling and managing how your on-premises applications communicate with your cloud applications, ensuring a single policy across your whole data center, on premises or in the cloud. Using Guardicore, any enterprise can build a single, secure policy and save time and resources, while ensuring best-of-breed security.

Check out this blog to learn more about Guardicore and security in Azure or read more about Guardicore and AWS security here.

Interested in cloud security for hybrid environments? Get our white paper about protecting cloud workloads with shared security models.

Read More

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

CAPTCHA ImageChange Image

‹ Back to Guardicore Blog