As organizations embrace a more dynamic and distributed work environment, securing access to private applications and sensitive data has become a paramount concern. Zero Trust Network Access (ZTNA) control provides a transformative approach to network security that prioritizes identity-based access and trustworthiness, regardless of user location. This solution brief outlines the principles and benefits of ZTNA for securing access to private applications and how you can use it in Exium's platform.
Legacy Perimeter Security: Traditional network perimeters are no longer effective in protecting against modern threats, particularly in remote and cloud-based work environments.
User Mobility: Users require access to private applications from various locations and devices, making traditional security models obsolete.
Application Diversity: Organizations deploy private applications across on-premises and cloud environments, adding complexity to access control.
Data Protection: Safeguarding sensitive data and ensuring compliance with data privacy regulations are critical concerns.
Zero Trust Network Access Control offers a transformative approach to securing private applications and sensitive data. By focusing on identity-based access, continuous verification, and least privilege principles, organizations can effectively mitigate security risks, enable user mobility, and achieve compliance while maintaining operational efficiency.
Feature |
Description |
---|---|
Identity-Centric Security | ZTNA focuses on verifying the identity of users and devices rather than relying on network location. Authentication is required for all access attempts. |
Least Privilege Access | Users are granted access only to the specific resources and applications they need to perform their tasks, reducing the attack surface. |
Continuous Verification | Implement continuous monitoring and verification of user and device trustworthiness during the entire session, enabling real-time threat detection. |
Micro-Segmentation | Network segments (referred to as Trust Paths in Exium's admin console) are created to isolate applications and resources, restricting lateral movement of attackers. |
Single Sign-On (SSO) | Streamline access with SSO solutions, allowing users to securely authenticate once and access multiple private applications. |
Comprehensive Visibility | Gain deep visibility into user activities and network traffic to detect anomalies and respond to security incidents. |
Policy-Based Control | Define granular access policies based on user roles, device attributes, and application sensitivity. |
Enhanced Security: ZTNA prioritizes identity-based security, reducing the risk of unauthorized access, data breaches, and lateral movement by attackers.
User Mobility: Users can securely access private applications from anywhere, fostering productivity and remote work.
Compliance: ZTNA helps organizations meet data protection and privacy regulations by enforcing access controls and monitoring user activities.
Efficiency: Least privilege access and SSO streamline user authentication and resource access.
Scalability: ZTNA is adaptable to the evolving needs of organizations, regardless of size and infrastructure complexity.
ZTNA is crucial for modern enterprises navigating the evolving threat landscape and the demands of remote and cloud-based work environments. You can create and apply ZTNA policies in the centralized admin console by following the steps below.
Exium enables workspace admins with multiple options to configure ZTNA policies. ZTNA policies are defined in the central admin console and applied in the Exium Cloud CyberMesh platform as shown in the above architecture diagram. Admins can define ZTNA policies to give full access to all services in a network (via trust paths) or limited access to specific services in a network. We also allow a combination of these two methods where one group can be given full access and another group a limited access.
ZTNA Policies |
Workspace level |
Group level |
User level |
Policy Definition | Applies to all users in the workspace or in the organization | Applies to all users in the group | Applies to a particular user |
Full Access to all services in a network (Trust Path level) |
√ |
√ |
√ |
Limited Access to specific services in a network |
√ |
√ |
√ |
Policies override precedence/ order |
Lowest |
Middle |
Highest |
Admins can attach override policies at higher precedence. User level policies are at the highest precedence, followed by the group level policies and finally workspace level policies are at the lowest precedence.
The following sections assume that you are familiar with Exium Secure Private Access (SPA) solution and you have already created and deployed at least one Cyber Gateway.
Full access to all services in a network can be defined by assigning workspace or group to a TrustPath linked to that network subnet.
You can define ZTNA policies at workspace level which will be applied to all users in the workspace. To create ZTNA policies, Follow below steps
ZTNA policies gets applied to all users in workspace immediately after submit. All users in the workspace will be able to access all services that are part of this network subnet.
You can define ZTNA policies at group level which will be applied to all users in that group. To create ZTNA policies at the that group, follow the below steps
ZTNA policies gets applied to all users in that group immediately after submit. All users in that group will be able to access all services part of this network subnet.
Limited access to all services in a network can be defined by defining the specific IP policies at the workspace, group or user level.
For limited services access, Trust Path should NOT be added to the Workspace or to any group. This field in Trust Path shall be empty. This creates a default “Deny All” mode where you need to selectively enable access to the services by following the instructions in this section.
Please follow following steps to create a Trust Path without workspace or group access.
At this step Exium mesh learns how to route the packets to this network subnet but none of the users in the workspace can access these resources. As a next step admins can give limited access to some services in a network.
You can define limited ZTNA policies at workspace level which will be applied to all users in the workspace. To create ZTNA policies, follow the below steps
On Create Policy form, follow below steps
Limited ZTNA policies gets applied to all users in workspace immediately after submit. All users in workspace will be able to access the specific service defined in this policy.
You can define limited ZTNA policies at group level which will be applied to all users in that group. To create ZTNA policies, Follow below steps
On Create Policy form, follow the below steps
ZTNA policies gets applied to all users in that group immediately after submit. All users in that group will be able to access the specific service defined in this policy.
You can define ZTNA policies at user level which will be applied to all users in that group. To create ZTNA policies, Follow below steps
You can define the policy as shown in the previous steps. You need to select All Rules in policies table before creating the policy
To Assign the policy to User, follow below steps
ZTNA policies gets applied to the user immediately after submit. User will be able to access the specific service defined in this policy.
Admins can attach override policies at higher precedence. User level policies are at highest precedence, followed by the group level policies and finally workspace level policies are at lowest precedence.
When a user belongs to multiple groups and if the same domain is defined in multiple policies attached to multiple groups or workspace, the ZTNA rule part of a group which has highest level of precedence will be applied.
We provide some examples below to clarify this. For all the examples, userA is assumed to be a part of a group groupA.
Example |
Workspace |
Group |
User |
Policy in Play |
---|---|---|---|---|
1 | Blocked | Allowed | NA | If 10.31.3.0/24 is Blocked at workspace level and if ssh(22) to 10.31.3.3 is Allowed at groupA level, for all users part of the groupA (including userA), can access ssh(22) to 10.31.3.3 . For the users not in groupA, ssh(22) to 10.31.3.3 will be blocked. |
2 | Blocked | NA | Allowed | If 10.31.3.0/24 is Blocked at workspace level and if ssh(22) to 10.31.3.3 is Allowed at userA level, only userA can access ssh(22) to 10.31.3.3 . For all other users, ssh(22) to 10.31.3.3 will be blocked. |
3 | Blocked | Allowed | Blocked | If 10.31.3.0/24 is Blocked at workspace level, ssh(22) to 10.31.3.3 is Allowed at groupA level and ssh(22) to 10.31.3.3 is blocked at userA level. For userA ssh(22) to 10.31.3.3 will be blocked, while for all other users part of groupA (excluding userA), ssh(22) to 10.31.3.3 will be allowed. For the users not in groupA, ssh(22) to 10.31.3.3 will be blocked. |
Exium provides Policy Precedency View (Generic Group level view and per user view) which will help admins to get an overview of all the policies placed in different groups and workspace level in the order of precedence.
To view Overall policy view, click on Policy View under Users and Devices in left menu bar and select Group View tab as shown below
Note the subnets shown with tp in front (Example, tp.10.30.1.0/24) are the Trust Paths that you configured for Secure Private Access.
To view User level policy view, click on Policy View under Users and Devices in left menu bar and select User View tab. Select a user from drop down as shown below.
You can also use this page to test a IP at user level to check if that IP will be blocked for that user or not. In User View, you can enter a IP and see the result as shown below.
To learn more about implementing SASE for your organization and explore tailored solutions that meet your unique requirements, contact Exium at hello@exium.net for a consultation or demonstration.