Skip to main content

Tutorial: Use CloudConnexa for Zero Trust Network Access (ZTNA)

Abstract

This tutorial shows how to use CloudConnexa as a ZTNA-capable solution. Whether on-prem or remote, everyone has to use CloudConnexa to access applications. Device identity, location context, and device posture checks are used. ZTNA checks are used for internal private applications, internet access, and SaaS applications.

Overview

Owen is the IT and Network lead for a Finance company with an office in Chicago. The company has undertaken an initiative to modernize its IT and Network infrastructure and rely more on SaaS-based solutions. However, some applications crucial to business operations run on the company's office network.

Owen’s objectives are:

  • Use one ZTNA cloud-delivered solution for office network security (unifying on-prem and remote access security policies), private app access, secure web access, and SaaS protection.

  • Least privilege access should be provided to both private and SaaS apps based on roles configured in Microsoft Entra ID.

  • Only company-owned Windows devices with Microsoft Defender can access private apps, the internet, and sanctioned SaaS applications.

  • Ensure that the financial brokers have access only when they are in the office location.

  • Ensure that policies for secure web access and acceptable internet use are followed.

Solution

To unify security policy and enforcement, regardless of location, direct access to private applications from the office network should not be allowed. The private application servers should be isolated in a subnet, and the firewall rule should be set to only allow access to that subnet from the CloudConnexa Connector. This will ensure that even when connected to the office network, users must use CloudConnexa to access private apps.

To enforce least privilege access, SAML can be used to authenticate with Microsoft Entra ID and to map the department or other attribute to CloudConnexa User Groups. Then, Access Groups can be configured for the various User Groups.

Device Posture policies can be set to allow only security-compliant and authorized devices to connect to CloudConnexa and access the configured resources.

Configure the SaaS applications as Applications so that only the traffic to those internet destinations is routed to the office network. Apply IP address restrictions within the SaaS apps to only allow logins from the office network. For example, setting Allowlisting IP addresses in Bitbucket can ensure that CloudConnexa is used to access Bitbucket.

Location Context policy can be used for the financial brokers' user group to set the office network as the only location from which they can connect and stay connected to CloudConnexa.

Cyber Shield can be used to implement DNS-based filtering (content filtering or web filtering) to protect against cyber threats and enforce the company's Employee Internet Usage Policy.

In addition, CloudConnexa provides features, such as DNS logs and Access Visibility , to check that the policies are enforced and to monitor user activity.

Configuration on CloudConnexa

To achieve his objectives, Owen configured CloudConnexa by following the steps below:

  1. Owen signs up for CloudConnexa and registers technop as Cloud ID.

  2. He logs into the Administration Portal at https://technop.openvpn.com, navigates to Users > Groups, and adds user groups to represent the various roles that have different access privileges, such as Brokers_Team for the financial brokers.

  3. Next, to represent the office network and connect it to CloudConnexa's closest Region, he navigates to Networks > Networks, clicks Add Network, and selects Remote Access from the network scenario choices presented by the configuration wizard.

    1. Owen chooses between the IPsec and OpenVPN Connector options to connect his office network to CloudConnexa.

    2. He adds Applications using the domain names of all private applications and restricts the protocols to access them.

    3. He adds Applications for the sanctioned SaaS apps, including Bitbucket, using their domain names. This ensures that the traffic to those SaaS apps is routed from CloudConnexa to the office network before transiting to the internet. The SaaS traffic thus gets the source IP address of the office network.

    4. He adds an IP service for the DNS server's IP address on the office network so that CloudConnexa has an IP subnet route to the office network for the DNS server.

    5. Next, he configures Access Groups to provide the user groups added with appropriate access to private and SaaS apps.

  4. For the Access Groups to take effect, he changes the WPC topology to Custom and deletes the default Default Full Mesh Access Group.

  5. To resolve the private app domain names, he sets CloudConnexa to use the office network's DNS server.

  6. To test connectivity and access to the private and SaaS apps, Owen navigates to Download App in the left nav to download and install the Connect App and import the profile after authentication. The Download App page also provides instruction on how employees can get connected.

    Once connected to CloudConnexa, he checks that he can access the private apps and that the office network is routing the SaaS application traffic.

  7. He now configures SAML Single Sign On by navigating to Settings > User Authentication for Entra ID, which includes setting up Attribute and User Group mapping. He also configures SCIM.

  8. He adds all User Groups to a device posture policy that he adds in which he disables access for macOS, iOS, Linux, and Android devices only allowing Windows devices. He adds a client certificate check and a Microsoft Defender antivirus check for Windows devices. This client certificate check will ensure that only authorized company-owned Windows devices possessing a certificate matching the one uploaded as a .pem file in the configured device posture policy are allowed to connect.

  9. He adds a location context policy to the Brokers_Team User Group, which blocks connections that do not match the office network's public IP address subnet.

  10. For secure web access, Owen turns ON Cyber Shield domain filtering, selects Custom protection level, and selects the content categories to block according to the internet use policy and for cyber threat protection.

Device configuration

Owen installs certificates, signed by the root or intermediate certificate uploaded in the device posture policy, in all company-owned Windows devices' Current User/Personal folder. He uses the Microsoft Intune device management solution to do this.

He can also use device management software to install OpenVPN Connect 3.6.0 and later manage all configurations, including providing the configuration profile file using the OpenVPN Connect application's global config file.

Configuration on SaaS tools

The security configuration section of most SaaS applications has a setting to allow access only from a set of IP addresses, which are called whitelisted or allow-listed.

Owen configures this setting for all the sanctioned SaaS applications to only allow logins from the office network's public IP address.

He also periodically monitors DNS logs to check whether employees use unsanctioned SaaS applications.

In this section: