User Guide: Zero Trust Application Access
Overview
Solution
Owen, the IT and Network lead, for a company that is headquartered in Chicago and has a branch office on the west coast. They have undertaken an initiative to modernize their IT and Network infrastructure and rely more on SaaS-based solutions. They however have some legacy systems crucial to their business operations. They have transitioned to using OneLogin as its IDaaS provider for Single Sign-On (SSO) implementation. They are looking to eventually decommission their hardware-based WPC and move to a Network as a Service solution. They still want to maintain some of the critical and sensitive systems on-site.
Owen’s objectives are:
Create a Site-to-Site Private Network between HQ and branch Networks as well as for remote WPC service.
Provide secure access to all the on-site applications based on departmental roles.
Provide secure access to a partner company that does audits on their financial system.
Employees and partners should be able to access applications using the private domain names that are already in use.
The high-level steps for Owen to achieve his objectives are as follows:
Owen decides to implement some of the zero-trust principles for this service. The private corporate Network is not treated as a trusted Network when accessing critical applications. For access to those services, the User needs to connect to the WPC even if they are on-site. This enforces that User identity is authenticated and the Device is authenticated by the use of certificates. If the Device is compromised, the certificate can be revoked. After authentication, only authorized Users are provided access to the application. This strict zero-trust access policy along with the additional layer of web application authentication by the finance application makes for a strong access security model.
Owen segments the HQ Network into 3 subnet ranges. These 3 subnets were isolated from each other using firewalls and VLANs but have connectivity to the internet. Network firewalls can be set to block all incoming requests because all valid traffic will come via OpenVPN tunnels. The OpenVPN connections are outgoing connections from the Connectors to the Regions. One of these subnets, named ‘critical app subnet,’ is dedicated to Network together application server infrastructure for internal use by select groups of employees. Another subnet, named ‘common HQ Network,’ is used to Network together applications, servers, and end-user computing resources that are generally needed for standard business operations. The private DNS server, print servers, etc. are in this Network. The remaining subnet is used to Host extranet application servers like the financial application.
Three Networks are configured one each for the branch Network subnet range, HQ ‘critical app subnet,’ and ‘common HQ Network,’
Services are configured for the HQ ‘critical app subnet,’ Network to represent each of the critical applications so that role-based access control can be enforced.
The 3 servers that form the financial application are configured as a Host with multiple Connectors and their WPC IP addresses are configured to enable round-robin load sharing in the private DNS server.
Access Groups need to be used to allow access of specific User Groups to applicable Networks, Hosts, and Services.
To enforce role-based access control using SSO, the department of the employees need to be passed as a SAML attribute and mapped to User Group.
High-Level Connectivity
Employees and resources connected to the Branch Network and the ‘Common HQ Network’ can access each other via CloudConnexa. Any User needing to access the Financial App Host or any of the applications on the ‘Critical App Subnet’, irrespective of whether they are in the HQ and Branch office locations or remote, has to set up a WPC from their computing Device to CloudConnexa in order to ensure zero trust access.
Setup
Owen has completed the signup process as shown here.
Owen created User Groups corresponding to the proper departments and roles that are authorized to use the internal applications. He set Connect Auth to value every time so that the WPC Users need to always enter their credentials when they connect to the WPC.
User authentication was then set up to use SAML with OneLogin. He set up mapping from the IdP-configured groups to the CloudConnexa groups that he had configured in the previous step.
Owen defined a Network with the subnet assigned to ‘Common HQ Network’, and installed the Connector on a computer running on the subnet to connect it to the Chicago Region.
Next, he added the Branch subnets as a Network and followed the Site-to-Site guide. He made the needed configuration for the Connectors and routing on both sites.
He changed the DNS server to the private DNS server that is part of the ‘Common HQ Network.’ Now, all the hostnames will be resolved by the company’s private DNS server to private IP addresses assigned to those Devices.
Owen defined another Network with the subnet assigned to ‘Critical App Subnet’ and installed the Connector on a computer running on the subnet to connect the Network to the Chicago Region. This is the subnet that is in HQ and dedicated to application servers.
He defined services for the ‘Critical App Subnet’ Network with each service corresponding to an application that needs to be available to authorized employees.
Next, Owen defined a Host to represent the financial application that needed to be accessed by external auditors and created 3 Connectors for it. Each Connector was installed on one of the application webserver.
When each Connector was created, the CloudConnexa Administration portal also showed the WPC IP address assigned to it. This WPC IP address does not change and was used by Owen to set up DNS records and implement round-robin distribution for the service name assigned to the financial application.
The last step was to create Access Groups such that access is authorized for:
Branch Network to Common HQ Network
Common HQ Network to Branch Network
User Groups Finance and Auditors to Finance App Host
User Group HR to service HRMS
User Group ‘IT Admin’ to service SSH
Finally, the WPC topology was changed to Full Mesh from Custom so that the Access Groups would be enforced.