Which Approach Is Better When Choosing a CASB? API or Proxy? How About Both?

By Bob Gilbert, Vice President/Product Marketing, Netskope

There have been recent articles and blog posts arguing that the API approach is better than the proxy approach when it comes to selecting a cloud access security broker (CASB). The argument doesn’t really make sense at all. Both surely have their advantages and disadvantages, but each covers unique use cases and while you could certainly select a CASB that supports one versus the other, why not choose a CASB that offers both so you have the option to combine the two and address expanded use cases?

Pitting one against the other is like comparing a spoon vs. a fork. A spoon was designed to hold softer food in addition to liquid so you can place it in your mouth and eat a meal. Spoons come in various sizes depending on the application. In a similar fashion, an API deployment method is primarily focused on a set of specific use cases that includes being able to inspect content in sanctioned cloud apps and support for out-of-band policies such as restrict access, revoke shares, quarantine, and encrypt.

A fork on the other hand, was designed primarily to grab and hold solid foods for eating. That is a job that the spoon cannot do. In a similar fashion, a proxy deployment method is primarily focused on a specific set of use cases around providing real-time visibility and control over cloud traffic and depending on the type of proxy, you can cover both sanctioned and unsanctioned cloud apps in real-time. Real-time and covering unsanctioned cloud apps is not possible with an API deployment method. In addition to use cases, there is the comparison of effort to deploy and use. You can argue that a fork requires a bit more care versus a spoon. You might not give that fork to a toddler for example, but a spoon would be less risky with trade-off of course that they might have a hard time eating their vegetables with that spoon. Similarly, a proxy requires and inline deployment and a forward-proxy specifically requires extra configuration and care. The effort can be worth it given the use cases.

Let’s get back to my original argument that why choose one versus the other? Choose a CASB that covers both an API method of deployment and multiple proxy methods of deployment. You can choose only one or combine them to expand your use case coverage. Should we start calling API + Proxy a spork?

Here is a table that compares use case coverage for API vs Proxy to help you make the decision which one to choose or perhaps choose both.