When enterprises embark on a cloud security project, they usually discover pretty quickly that there are multiple ways to deploy a cloud access security broker (CASB). Deciding on the right architecture for your project is one of the most important decisions you’ll make since it impacts what CASB features you’ll be able to apply to which users, devices, and services and under what conditions. The enforcement point in the on-premises era was clear – it was at the network edge. In the cloud era, the perimeter is undefined. When deploying a CASB, how do you ensure you have visibility and control over all users, all devices, and all cloud services?

The primary deployment modes for a CASB include:

  • Log collection – consuming event logs from existing infrastructure such as firewalls, secure web gateways, and SIEMs. Generally, logs capture user activity but not content.
  • Forward Proxy – inline deployment between the endpoint and cloud service in which the device or network routes traffic to the CASB proxy.
  • Reverse proxy – inline deployment between the endpoint and cloud service in which the cloud service or identity provider routes traffic to the CASB proxy.
  • API – direct integration of the CASB and cloud service. Depending on cloud provider APIs, the CASB can view activity, content, and take enforcement action.

Deciding on the right architecture for your project goes beyond ease of deployment, although this is an important consideration. There are key CASB features that, due to the nature of how they work, are only available in one or more deployment modes and not for others. When assessing a CASB, you’ll want to confirm the solution supports deployment modes you need now and in the future. In most cases, enterprises combine multiple deployment modes to achieve complete coverage. In Gartner’s latest CASB report How to Evaluate and Operate a Cloud Access Security Broker (download a complimentary copy here), they note:

Increasingly, a growing number of CASBs offer a choice between proxy modes of operation and also support APIs. Gartner refers to this as ‘multimode CASBs.’ They give their customers a wider range of choices in how they can control a larger set of cloud applications.

– Gartner, How to Evaluate and Operate a Cloud Access Security Broker,
Craig Lawson, Neil MacDonald

Deployment Architectures for the Top 20 CASB Use Cases

Download this ebook with deployment architectures that support the top 20 CASB use cases.

Download Now

CASB features supported by each deployment mode

At Skyhigh, we offer all four CASB deployment modes and customers frequently ask us which ones are right for their use cases. The availability of a feature is not just dependent on whether a vendor has built it, it’s dependent on whether that feature is even feasible in that architecture. Simply put, some features are possible in one architecture, but not in another. For example, you can scan data stored at rest via cloud app APIs, but you cannot scan data already stored in the service via an inline proxy. We’ve compiled a reference below showing key CASB capabilities and whether they are feasible for each deployment mode.

Log Collection Forward Proxy Reverse Proxy API
Top-level usage statistics (which employees use which services)

·

 

 

 

Risk assessment (risk profile of cloud services in use)

·

 

 

 

Detect enforcement gaps (access of apps not effectively blocked)

·

 

 

 

Collaboration analytics (sharing permissions on files/folders)

 

 

·

Activity monitoring (audit trail of user and admin actions)

·

·

·

·

Detect insider threats

·

·

·

·

Detect compromised accounts

·

·

Detect malware (exfiltrating data via unsanctioned apps)

·

 

 

 

Detect malware (stored within sanctioned apps)

 

 

 

·

DLP inspection (data at rest  within sanctioned apps)

 

 

 

·

DLP inspection (data in transit)

 

·

·

DLP enforcement (quarantine, delete, modify collaboration)

 

 

 

·

DLP enforcement (block, tombstone)

 

·

·

 

Security configuration audit (security settings of apps)

 

 

 

·

Encrypt data (at rest in cloud apps)

 

 

 

·

Encrypt data (in transit to the cloud)

 

·

·

 

Decrypt data (for end-user access)

 

·

·

 

Manage access (based on device, user, location)

 

·

·

 

Policy-based authentication (require two factors)

 

·

·

 

Apply rights management (to data on download or upload)

 

·

·

 

While this table is a simplification and there are nuances not captured here, it gives a good overview of what capabilities to expect with different CASB architectures.

Log collection is a natural starting place for many CASB projects because companies need to scope their cloud usage before determining their security policies and priorities. Log collection, when paired with a robust cloud registry, provides a high-level overview of all cloud apps in use, data volumes uploaded to the cloud, and the risk of those apps. For enterprises that decrypt SSL, these logs can also provide detailed insight into the activities performed within cloud apps. However, logs from egress infrastructure do not provide insight into the content flowing to and from the cloud. For visibility into content, you will need an inline proxy and/or direct API connection to the app. Log collection is also a monitor-only mode, with the caveat that you can enforce coarse level allow/block policies for cloud services if your CASB integrates with your firewalls and proxies. To enforce granular policies based on specific data types and activities, you will need to augment log collection with another mode.

The two inline proxy modes – forward and reverse proxy – offer a similar set of capabilities. The real difference between the two comes down to coverage for users, devices, and access scenarios. We will cover those in the following sections. For now, note that both inline proxy options offer the ability to inspect content to and from the cloud and enforce real-time policies (such as blocking an upload to an app, stopping download to an unmanaged device, etc.) While a CASB can encrypt existing data in a sanctioned cloud app via API, an inline proxy is needed to decrypt data for end users accessing the app, so they see their data, not cipher text.

The API mode is the only way to inspect content stored at rest within cloud apps since an inline proxy only has visibility into data uploaded to the app after the proxy has been deployed. Since many enterprises already have a large volume of data stored in the cloud, the API mode is used to enforce policies on this data. Other capabilities only possible when connecting directly to an app via API include the ability for the CASB to scan security configuration settings within the app and suggest changes that bolster security, as well as the ability to scan the sharing permissions on files and folders to assess the risk of third-party and external access to corporate data.

Now that we’ve looked at what core capabilities are possible in each deployment mode, let’s take a deeper look at coverage for cloud access scenarios commonly found in enterprises today:

  1. Sanctioned vs. unsanctioned apps
  2. On-network vs. off-network users
  3. Managed vs. unmanaged devices
  4. Data at rest vs. data in motion

IT control over the app

If you’re like most organizations, your employees use a combination of cloud apps that are sanctioned and delivered by the IT department, as well as apps employees introduce themselves that are not sanctioned by IT. Within the apps that are not sanctioned by IT, you find a mix of apps that IT may choose to permit, as well as those that are not suited to store corporate data. To fully secure corporate data in the cloud, you need to consider sanctioned and unsanctioned cloud applications and deployment architectures that cover each.

Cloud Graph

If you think about the placement of a visibility and enforcement point for the cloud, sanctioned and unsanctioned applications present very different scenarios. For unsanctioned cloud apps, you want to ensure the broadest range of coverage for all cloud apps that employees use. Log collection and forward proxy modes are both first-mile deployment modes – they provide coverage for all apps that a user accesses. For sanctioned applications managed by IT, it makes more sense to focus on enforcement at the last mile to extend coverage to the broadest range of users. Both API and reverse proxy modes are well suited to provide complete coverage for all users and devices accessing a specific cloud service managed by IT.

Unsanctioned Sanctioned
Log collection (monitor only)
Forward proxy
API
Reverse proxy
Forward proxy

Unsanctioned cloud apps – which may or may not be permitted – fall under the log collection and forward proxy modes. Collecting logs from egress infrastructure provides coverage for all cloud apps in use by the user. Similarly, routing cloud traffic through a CASB’s forward proxy provides deep content-level visibility and control for unsanctioned cloud apps. There are key functional differences between these two modes that are outlined in the preceding section. Log data generally captures usage and individual activities, but not content. The forward proxy mode adds support for content inspection and inline control.

The most common deployment modes for sanctioned apps managed by IT are API and reverse proxy. Both may be deployed to provide broader feature coverage not available in one mode or the other (e.g. data at rest and in motion). Since a sanctioned app is managed by IT, it’s possible to connect the CASB to the cloud app via the cloud provider’s API for visibility and policy enforcement. Similarly, IT can configure traffic routing after authentication through the CASB’s reverse proxy. While a CASB’s forward proxy mode can be used to secure sanctioned cloud apps, there are some device limitations that, in practice, make the coverage for API and reverse proxy modes more comprehensive. We’ll cover that in the next section.

Device and access scenarios

Log collection is well suited to provide coverage for on-network access of cloud apps. On the network, a firewall and SWG capture traffic destinations in their log files. Managed devices off-network that are configured to route traffic through a cloud-hosted SWG provide additional insight into cloud activity for corporate users on the road or at home. There are many similarities between the device and access scenarios that log collection and forward proxy support. They both provide coverage for on-network devices, as well as off-network managed devices. They do not provide coverage for off-network unmanaged devices.

On-network Off-network
Managed Log collection
Forward proxy
Reverse proxy
API
Log collection
Forward proxy
Reverse proxy
API
Unmanaged Log collection
Forward proxy
Reverse proxy
API
Reverse proxy
API

There are several ways to route traffic through a CASB’s forward proxy. Similar to an SWG deployment, you can install an agent on the endpoint or configure the network to route traffic through the CASB. Many organizations have already deployed a secure web gateway (SWG), and in this case, you’ll likely want to chain cloud traffic from the SWG to the upstream CASB proxy rather than split traffic at the endpoint. Proxy chaining has the benefit of avoiding a potentially painful agent rollout and ensuring cloud traffic does not bypass controls in your SWG.

One of the limitations of the forward proxy architecture is that it does not cover off-network unmanaged devices. The reverse proxy mode covers the same device and access scenarios as the forward proxy mode as well as off-network unmanaged devices. A reverse proxy can support this access scenario because traffic is routed in the last mile during authentication to a cloud application, and therefore the CASB covers all users regardless of their device or network. With growing acceptance of BYOD and remote work, this deployment mode ensures coverage for employees who access cloud apps from personal devices from anywhere – whether the office or the coffee shop.

The API deployment mode connects directly to a sanctioned cloud app via standard APIs and therefore provides coverage for that app regardless of the user’s device or network.

Type of data

Broadly speaking, there are two types of data: data stored at rest in cloud apps and data that is in transit to or from the cloud. It turns out that while the API mode for CASB provides excellent coverage for data stored at rest since its enforcement options rely on the cloud provider, not all enforcement actions are possible. For example, most cloud provider APIs that are leveraged by CASBs do not support real-time controls such as preventing the download of sensitive data to an unmanaged device (while allowing the device to preview the content).

Data at rest Data in motion
API API (near real time)
Forward proxy (real time)
Reverse proxy (real time)

While neither inline proxy modes for CASB cover data already stored at rest in the cloud, they do enable real-time controls. For example, a CASB in proxy mode can block the download of a file containing sensitive data to an unmanaged device that does not have adequate endpoint security controls such as encryption and a password lock. They also ensure that policies are enforced before data even reaches the cloud. For some enterprises, waiting a few seconds for a CASB to enforce a control via API is not fast enough, they need the policy to be enforced before the action occurs within the app. Both proxy modes meet that use case.

For this comparison, we have excluded log collection because, while it provides insight into activity, it does not support content inspection for data in the cloud.

Putting it all together

No single CASB deployment architecture covers all cloud applications, users, and devices under all conditions. For this reason, most CASB projects involve multiple deployment modes working together to provide visibility and enforcement coverage that meets the needs of the enterprise. By assessing the functionality, apps, and users that are most important to you, you’ll be better positioned to prioritize your rollout of a CASB. Skyhigh has helped over 600 enterprises securely enable their use of cloud services. When you’re ready to begin a cloud security project, our team of cloud enablement specialists would be glad to assist you in mapping out a solution architecture that meets your needs.