Tutorial: Zero trust access to SaaS applications using cipherscale

Scenario

Rob is the CTO of AIStar, an AI startup based in Chicago. All his employees are remote workers from all over the USA. They rely primarily on SaaS applications such as Workday, Salesforce, etc. The developers maintain application code in repositories managed using BitBucket. He has provided his team with company-owned laptops. They use Microsoft Office 365 and Microsoft Entra Identity as an IDaaS provider.

Rob wants a solution to protect SaaS applications by isolating them from public internet access, which can lead to credential stuffing and other attempts to hack into accounts. He wants to enforce zero trust principles based on user identity, location, and device contexts for the least access privilege to SaaS apps.

He wants to achieve the following:

Provide access only to company-owned devices that are running the endpoint protection software.

Provide access to devices located in the USA and only during business hours.

Microsoft Entra ID should be used for SSO.

Least privilege access rights should be granted for SaaS tools based on department. For example, provide access to Bitbucket only to developers, Workday only to HR, and Salesforce only to Sales.

Exceptions to department-based privileges should be made for specific users and devices.

All data communications should be encrypted end-to-end from the device to an access point under the control of the company’s IT department.

Employee access to the SaaS apps must be blocked from the internet.

Solution

Rob determines that cipherscale meets his business needs and plans to use cipherscale in the following manner:

Deploy cipherscale gateways in a public cloud data center near San Francisco, Chicago, and Boston. These gateways located closer to the remote employees will improve their internet speeds.

Configure cipherscale admission rules to check for user location, time of day, and device posture to meet the location, time, and device requirements. He plans to use a digital certificate to identify company-owned devices.

Push the digital certificate and the cipherscale app to the company devices using an endpoint management system.

Configure SaaS applications such that all the deployed gateways can be used to access them.

Add the public IP address of the networks on which the gateways are deployed as the allowed IP ranges from which logins can be accepted for all approved SaaS tools like BitBucket. This setting isolates the SaaS apps from all other login attempts from the internet and only accepts and authenticates those coming from cipherscale gateways.

Create cipherscale groups corresponding to the departments and use them in cipherscale access policies, providing them the least privileged access to the configured SaaS applications.

Add specific access policies to grant or deny access to resources as an exception to group policies to users/devices and order them before the group policies in priority.

Use SAML to authenticate with Entra ID and map the department attribute values to the corresponding cipherscale groups.

Configuration

Rob signs up for cipherscale, provides ‘aistar’ as a name for his cipherscale space, and starts using the administration portal for configuration.

He creates Groups for all departments in his company. See adding groups

He disables Google and Microsoft OAuth for user authentication because that will not provide the user's department information. See changing user authentication

He configures SAML for user authentication with Microsoft Entra ID and enables it to be the only user authentication method.

He maps the values received from Entra ID for the department to the cipherscale Groups. See SAML configuration.

Next, Rob creates an Admission Rule named aistar allowed. See add admission rule.

He adds a Location Context rule that only allows users from the USA.

He adds a Time Constraint rule that only allows access during business hours.

He adds a Device Posture rule that checks that the device runs Windows OS and has a certificate whose common name matches asistar.com.

He adds BitBucket as a SaaS application with the three gateways deployed, one each in Boston, San Francisco, and Chicago. He creates a new access policy developer_only, allowing only the Developer group access. The aistar allowed admission rule is used with this access policy. See add SaaS application, add gateway, add access policy.

On Bitbucket, from the Access controls page, he selects the Restrict access to certain IP addresses option and enters the public IP addresses of the three gateways. These gateways will use NAT to change the source IP address of the traffic going to BitBucket.

Rob adds all the other SaaS applications, adds the appropriate access policies, which provide access only to the groups that need it, and then restricts logins using the SaaS app’s security settings.

Employee experience

All employees have to use the cipherscale app and sign in using SSO to access SaaS applications, as direct logins from the internet are blocked by the SaaS app’s security settings. Cipherscale permits only devices with the digital certificate, Windows OS, and other criteria per the admission rule aistar allowed. Cipherscale will use one of the three gateways with the best-estimated data throughput performance.