Deployment Models
General
Most SaaS deployments involve access to the service from devices, users, and connected applications that are not managed internally. As a result, traditional in-line controls such as web gateways and firewalls are not well suited to secure these environments. Instead, a combination of API and Reverse Proxy architectures are used to enhance visibility and security for the SaaS
Figure 3 depicts how APIs provide coverage for most activity monitoring and data protection use cases while the reverse proxy provides contextual access controls some out-of-the-cloud data protection. The sections that follow provide an in-depth discussion of the benefits of these complementary architectures.
Figure 3 - CASB Architecture: Sanctioned SaaS
API Model
All mainstream SaaS applications offer various levels of controlling or monitoring the service using an API. The challenge with APIs is that they are designed to be consumed by application developers and do not provide policy logic, workflows, a front-end that is useful security teams, SOCs, or auditors.
A major function of the CASB is to leverage APIs of many SaaS vendors and provide a console from which to deploy consistent monitoring and controls. Although APIs and built-in functionality will vary from one SaaS provider to another, Skyhigh CASB smooths out these differences by augmenting native API functionality where it exists (such as receiving activity monitoring feeds) and adding needed functionality where it does not (such as preventing collaboration of only sensitive data).
Architecturally, the CASB API model for SaaS is one of see-and-react, in real-time or near real-time. This is facilitated by the live event stream Skyhigh CASB receives from the cloud provider, fast security event processing, and making cloud provider API calls to remediate the event where necessary. The following flow is an example of how a file with PCI information would be handled if it were accidentally uploaded to a cloud storage SaaS by fictitious user "Frank."
Example Event Flow
- Frank accidentally copies a payment card processing file (creditcards.csv) from his desktop to a cloud storage sync folder.
- The cloud storage provider transfers and places the file in Frank’s folder within the SaaS.
- A notification of the file put (or equivalent) event is sent to Skyhigh CASB via a webhook (or similar event push) API in near real-time.
- Skyhigh CASB calls the service provider’s API retrieve function to obtain a copy of the creditcards.csv file.
- Skyhigh CASB runs creditcards.csv against DLP policies PCI violations that should be remediated by quarantining the file.
- Skyhigh CASB calls the object’s move method and places it in a quarantine folder in a folder with restricted, admin-only access.
- Skyhigh CASB calls the service provider’s API put function and places a tombstone file called creditcards.csv in place of the original file.
NOTE: The event timeline varies by cloud provider, but generally takes less than 60 seconds. In some cases, such as with Office365 file sharing, remediation occurs instantaneously.
Key Advantages of API Model
- Frictionless deployment – Skyhigh CASB operating in API mode does not intercept traffic or change the native user experience in any way.
- Data-at-rest protection – API is the only CASB deployment model where scanning, tagging, and remediation of existing data-at-rest is possible.
- Immediate value – Since there is no infrastructure to deploy, Skyhigh CASB API mode sets up in minutes providing organizations immediate value.
- No reverse engineering – APIs interact with SaaS providers using a framework designed and published by them. As a result, they have a high degree of reliability and support from the providers compared to proxy-based solutions which rely on reverse engineering the web traffic.
Reverse Proxy Model
Certain use cases, such as conditional access, necessitate that a security layer is placed between the end user and the cloud service. For example, suppose an organization wishes to allow "kiosk mode" access to a SaaS where data can be viewed and edited within the browser environment but not downloaded to unmanaged machines. In this case, the reverse proxy evaluates the context of the user’s access to the service (e.g., user certificates, geolocation, SAML attribute, device type, etc.) and applies an access policy based on rules defined in the Skyhigh CASB dashboard (see Figure 4).
The Skyhigh CASB reverse proxy has an architecture like that of a Web Application Firewall, with a publicly facing endpoint front-ending HTTP(S) requests for services. When the reverse proxy is created for a cloud service, it is assigned a subdomain under the customer’s domain name. For example, if the SaaS being secured was Microsoft Office 365, the subdomain would commonly be office.customer.com. When users access office.customer.com, their requests are forwarded by the reverse proxy so that office.customer.com looks and feels to the end-user like office.com. Since SaaS services are publicly accessible, however, some mechanism is required to ensure that requests to the SaaS are routed through the reverse proxy.
A marked advantage of the reverse proxy model, particularly over that of the forward proxy, is that there is no need to have control over the endpoint to drive traffic through the proxy. Instead, connections are automatically routed to the reverse proxy following authentication through a SAML compliant identity provider such as Ping, Okta, or Active Directory Federation Services (ADFS). To facilitate this, a three-way certificate trust relationship is first established between the cloud service, the identity provider, and Skyhigh CASB. Then the SAML endpoints (or relying party URL) are modified within the identity provider to reflect the URL of the reverse proxy rather than the original for the SaaS. The result is that following successful authentication, users receive a SAML assertion for, and are redirected to, the reverse proxy.
When policy permits direct access, such as when the device is properly managed/secured, the Skyhigh CASB reverse proxy writes a new SAML assertion with the original SaaS URL and redirects the client there.
Figure 4 - Reverse Proxy Insertion via SAML
Example Event Flow
- Francis clicks her bookmark for SaaS application, MySaaS which takes her to mysaas.com to login where she enters her corporate credentials, francis@company.com.
- MySaaS has company.com configured as a federated domain and redirects Francis’ to obtain a SAML assertion from her corporate identity provider at sso.company.com.
- Francis enters her corporate credentials at sso.company.com and is successfully authenticated.
- ADFS consults its configuration for MySaaS and writes a SAML assertion granting Francis access the application via mysaas.company.com (the reverse proxy address) and redirects Francis’ browser there.
- Francis submits her SAML assertion to the Skyhigh CASB Reverse Proxy and applies an access policy based on the context of her connection, including SAML attributes passed from the identity provider, location, user certificates, device type, etc.
- If Francis’ context has met the criteria defined for a managed device, the Skyhigh CASB Reverse proxy writes a new SAML assertion for Office365 and redirects her browser there. Francis will access Office365 directly for the remainder of that login.
-or-
If Francis’ context has not met the criteria, her connection will continue to be proxied but will look and feel like native Office Typical restrictions on Francis might include preventing the connection of "thick" clients such as Outlook or OneDrive, and blocking downloads of sensitive data to the unmanaged machine.
Key Advantages of Reverse Proxy Model
- In-line controls – The Skyhigh CASB Reverse Proxy augments API-based controls to provide real-time, in-line security for cloud services limiting access to functionality and/or sensitive data based on the context of the device and user.
- Agentless – Through integration with a SAML-based Identity Provider, Skyhigh CASB provides agentless security to both corporate and personal devices based on their context.
- Universal – The reverse proxy is a framework that can "learn" most cloud applications and is an ideal deployment model for securing SaaS applications that do not support API-based security. In these cases, the Skyhigh CASB Reverse Proxy fills in the gaps and provides activity monitoring, DLP, encryption, and other security services.
- Email DLP – While technically deployed as an SMTP proxy, Skyhigh CASB also supports in-line email DLP based on context and content of emails sent out of cloud providers such as Microsoft Office365 and Google GSuite.