Controlling Access to SaaS Application Tenants with Header Injection

This article provides an overview of using header injection to secure your network by preventing access to private SaaS application tenants. For information about configuring tenant control with header injection rules, see Managing Tenant Control for SaaS Applications.

Use Case

In most corporate environments there are multiple SaaS applications that are used daily: email, CRM applications, productivity, etc. While this is extremely convenient, it does open a potential security risk for people to use personal accounts on those SaaS applications while connected to their company environment. For example, Company A uses Google Workspace for its email and productivity applications. User A also uses Google for their personal email and word processing. Company policy states that users are not permitted to access personal email or other apps on their corporate devices. What tenant control will do is only allow access to designated tenants of approved SaaS applications as a function of the Cato CASB solution.

Another example is if a device that is infected with malware is attempting to communicate with a third-party SaaS tenant. The tenant restriction will block access to other third-party applications that are not sanctioned via header injection.

For information about configuring tenant control with header injection, see Managing Tenant Control for SaaS Applications

How Does It Work?

The feature itself is quite simple in its architecture. The policies are a whitelist for SaaS applications in the corporate inventory. When a user accesses a SaaS application that has a tenant control policy in place, there is a packet header tag and value that are injected at the Cato inspection engine in the PoP. With this value in place, the packet follows the normal path to the Internet, and to the application. The enforcement of the policy actually happens in the SaaS application where you program your header and value to monitor for that header value and block all traffic that does not match the header value.

Traffic Flow

  1. A user enters both of the following URLs into their web browser. One goes to their corporate email portal, and the other goes to their personal email. Both portals are hosted in Google Workspace.

  2. The traffic goes to the Cato PoP, where a header item value is injected in all packets destined for Google mail.

  3. Cato routes the traffic to the Internet and to Google Mail.

  4. Google mail has a security parameter set that is looking for the header value.

  5. All traffic with the correct header value connects to their authentication page and to their mail Inbox. All other tenants are blocked at the SaaS application.

Was this article helpful?

2 out of 3 found this helpful


Add your comment