Five Steps to Zero Trust Network Access: Configuring ACL for User-Application Segmentation
Steps to Zero Trust Implementation
If you’re looking to build a strong zero trust strategy — or would like to benchmark your progress thus far — then this blog is for you.
This is the fourth installment in our 5-part BlackBerry blog series describing practical Zero Trust Network Access use cases (Part 1), how to employ ZTNA user personas (Part 2), and various ZTNA-relevant applications (Part 3). Here in Part 4, I’ll discuss the implementation of an ACL (access control list) policy, which significantly increases cyber resiliency.
Zero Trust Network Access: Configuring an Access Control List Policy
Think of ACL as the new NAC (network access control). In a ZTNA system, access control lists are essentially omnipotent: They can block everything, block specific things, allow all, allow access to private networks, and dynamically change rules based on risk posture at any given time. In the simplest terms, ACLs ensure just-in-time and “just enough” access.
A ZTNA solution with integrated ACLs can future-proof your zero trust evolution while transforming existing, often archaic network architectures.
The key to a successful ZTNA roll-out lies in configuring ACLs for user-application segmentation. The ease of creating segments at layer 7, and at layers 3 or 4, via airtight integration with identities, defines the extensibility of a ZTNA implementation. This means network administrators must define who can go where and under what conditions — with precision, clarity, and without duplication — for both simple and complex requirements.
In addition, admins and users must be able to easily read and verify their entire configuration for completeness and consistency. An ACL policy that allows drafting of ACL rules using an expressive framework can help in obtaining faster outcomes in a ZTNA project.
Defining ACL Pre-Requisites
A comprehensive ACL framework should identify the following:
- Rules with independent criteria (precision, one list, familiar, fully expressive)
- Destination address (where)
- User properties (who)
- Risk category (additional conditions)
- One list of rules for tenants (complete, read, verify, clarity, de-duplication, familiar)
- Ordered (refinement, precision)
- Network service (simple/complex configuration)
- Recursive aggregation (de-duplication)
- Ports and protocols (complex, flexible)
Clear definition of these elements empowers an administrator to accomplish several critical tasks: Creating ACL policies in a single integrated workflow; associating policies to a user’s risk profile; establishing air-tight integration with identities; allowing/denying connections through continuous trust assessment by authenticating/re-authenticating requests; and authorizing access to resources.
Planning for ACL Rules
Organizations can do up-front planning for access control list rules in a number of ways. Ideas include identifying and deconstructing network services, creating smaller perimeters, aligning content filtering rules with enterprise access policy, and defining risk levels. All of these steps can help streamline ZTNA implementation.
Network administrators must set, monitor, and manage access control for their users. Therefore, they should be equipped with a functional web interface to configure ACL rules within the scope of a single access control policy. Rule sets should be orderly and composable, so an administrator can either reuse definitions in multiple policies or refine rules for different types of users or risk levels.
A flexible, reusable, and expressive ACL policy set can address endless possibilities that may arise in the process of digital transformation. A common case for reuse is network service, a logical network application that users, via their endpoints, might attempt to access.
Putting ACL Rules Into Operation
Putting access control list rules into effect requires a clear understanding of both the specific applications and user personas to bring under a ZTNA umbrella. For instance, a single deployment may consist of multiple user personas needing access to different network applications and IdPs (identity providers), with necessary out-of-the-box and customized support.
Consider an example where a customer uses two network applications with two identity provider services — Microsoft 365® with ADAL (Active Directory Authentication Library) and Salesforce® with Okta® — for their initial launch. An IT administrator can set up separate network services, one for ADAL alone with its target set, and a second for Okta. The admin can then choose to define a network service for each application and aggregate them, or define a network service for each application directly with its own IdP. This creates a high level of flexibility, despite the IT administrator avoiding "pure" definitions of each application.
By extension, the admin may still reuse the ADAL and Okta network service definitions across multiple application network service definitions, each of which automatically recognizes changes made to those IdP definitions. Through planning, an organization can maximize the power of a network service to contain both a reference to some other network service, as well as an immediate target set.
What’s Next?
In the upcoming final Part 5 of this blog series, I will discuss organizational considerations to help maintain and support ZTNA beyond its initial implementation.
