SaaS and internal application protection

One of the most relevant use cases for Enclave gateways is to provide an secure access point that routes traffic to SaaS or internal applications. This can be useful for enforcing security policies or giving temporary access to an application without relying on the application itself to provide those features.

Use cases

• Protection for SaaS applications: By routing traffic through a gateway, you can utilize the enclave agent to enforce additional security policies and restrict access to SaaS Applications.
• Protection for internal applications: Gateways can be used to provide agentless access to internal applications that may not be exposed to the internet. This can be useful for providing temporary access to an application without having to expose it to the public internet.

Benefits

• Additional security: By routing traffic through a gateway, you can enforce additional security policies and monitor access to the application, reducing the risk of unauthorized access.
• Simplified access management: Using a gateway allows you to manage access to the application centrally, making it easier to grant or revoke access as needed.
• Reduced attack surface: By using a gateway, you can reduce the attack surface of the application, as it is not directly exposed to the internet.
• Easy to deploy: Gateways can be easily deployed and managed through the Enclave management console, allowing you to quickly set up and modify your network architecture as needed.
• Fully encrypted: All traffic routed from an agent to the gateway flows through encrypted tunnels, ensuring that your data remains secure.
• Agentless access: Gateways allow you to provide access to resources without having to install agents on those resources, making it easier to manage and secure your network.

How it works

With a virtual or physical gateway deployed in your enclave network, you can create an egress route that automatically routes traffic destined for a specific hostname or subnet through the gateway. This forces all traffic for an agent connected to this egress route to have it's traffic routed through the gateway for the specified hostname or subnet. That traffic now appears to orininate from the gateway's public IP address, allowing you to enforce security policies based on the gateway's IP address.

Usage with an identity provider (IdP)

A common authorization mechanism for SaaS applications is to use an identity provider (IdP) such as Microsoft Entra ID or Okta with OpenID Connect (OIDC). These platforms often provide the ability to create conditional access policies that restrict access to applications based on the source IP address of the request. By using a gateway with an egress route, you can ensure that all traffic to the SaaS application appears to come from a known IP address, allowing you to enforce these conditional access policies. Effectively a client needs to be authenticated to the IdP and be on the Enclave network to access the SaaS application.

The benefit of this approach is that you only need to route traffic to the IdP through the gateway, rather than all traffic to the SaaS application. This can help to reduce latency and improve performance, while still providing the necessary security controls. Since the IdP is in charge of authentication and authorization, you can leverage their robust security features to protect access to the SaaS application.

Usage with Microsoft Entra ID

First you'll need to setup your egress route on your enclave gateway. Microsoft makes their IPv4 subnet ranges available here. You will most likely be utilizing the login.microsoftonline.com endpoint for authentication. Since this hostname is DNS load balanced, you will need to add in the subnets that are given for the endpoint you are using instead of relying on the hostname. At the time of writing, for login.microsoftonline.com, these are: 20.20.32.0/19, 20.190.128.0/18, 20.231.128.0/19, 40.126.0.0/18.

Next you will create a named Location in your Entra account that will link to the public IP address of your gateway. This will be used in the conditional access policy to restrict access to only requests coming from your gateway.

Finally, you will create a conditional access policy that restricts access to your SaaS application to only allow requests from the named location you created in the previous step. This way, only agents connected to your enclave network can authenticate to your SaaS application, ensuring secure access to the application.

Usage for internal applications

You can also use a gateway to provide secure access to internal applications that may not be exposed to the internet. By creating an egress route that routes traffic destined for the internal application's subnet through the gateway, you can ensure that only agents connected to your enclave network can access the application. This can be useful for providing temporary access to an application without having to expose it to the public internet.

Agentless access to internal applications

If your internal application is hosted on a server that cannot have an enclave agent installed, you can still provide secure access to the application by deploying a gateway within the same network as the internal application. By creating an egress route that routes traffic destined for the internal application's subnet through the gateway, you can ensure that only agents connected to your enclave network can access the application, without needing to install an agent on the server itself. This allows you to provide secure, agentless access to internal applications, simplifying management and improving security.