What you call it changes how you think about it
Zero-trust architectures change the attack pattern from “network compromise” based attacks to “identity compromise” based attacks. It therefore becomes imperative to determine what any authenticated user can do once they are logged in. This is the area of access management or authorization. The goal of any technology in this space is to provide least-privilege access to users. This means users can seamlessly access what they need in order to do their jobs, and nothing more. Role-Based Access Control (RBAC) is a vastly popular technology in this space, and for the past decade, Attribute-Based Access Control (ABAC) is gaining increasing traction. Here are quick descriptions of RBAC and ABAC.
The goal of any authorization technology is to provide least-privilege access to users. This means users can seamlessly access what they need in order to do their jobs, and nothing more.
RBAC:
RBAC was the first step after an older technique known as ACLs (Access Control Lists) was found hard to scale and manage. In RBAC, each resource has a list of roles that are permitted access to it. In many real-world RBAC deployments, users are added to roles that contain “entitlements”, which are bundles of related permissions. Resources could mean anything from an internal “file share” to a specific functionality in a SaaS application. RBAC is by far, the most common way of implementing access control today.
ABAC:
One may think of “role” as being just one attribute (or characteristic) of a user, and as such the user may have more attributes, e.g. “office location”, “current projects”, and “clearances”. ABAC expands from matching the attribute named “role” (as in RBAC) to matching any attribute of the user to corresponding attributes associated with the target resource, as well as to the access context. For example, an ABAC policy may specify that the user whose “clearances” attribute includes “sensitive” can only access resources tagged with the attribute “sensitive” from their office location.
Attribute information can be contextual and more dynamic (e.g. access location is determined at the time of access, and project assignments may be more short term than a user’s role within an organization). As a result, ABAC offers a level of dynamism not offered by RBAC. ABAC policies also do not need to name specific resources (see the example policy in the previous paragraph), and hence they can (in theory) deliver fine-grained access control. For example, each file may have a different value for the “sensitive” attribute. Doing the same in RBAC will require one to define permitted roles on every file, making it intractably hard to manage.
ABAC policies do not need to name specific resources and hence they can (in theory) deliver fine-grained access control.
Of late, there is widespread recognition, among customers, analysts and (some) vendors alike, that existing authorization models aren’t sufficient by themselves. Here are some reasons why:
Coarse Grained Access: Today’s access management products only enable access decisions at a coarse grained level. As a result, users are provisioned with access to entire collections of unrelated data when they need access to only a small portion of it. For example, a customer service representative gets access to all customer data when they are granted access to the CSM system. Although ABAC held promise to solve this problem, it has been realized only in a limited way in the real-world
Static: Role memberships typically change only manually. ABAC policies too sometimes depend on manually set attribute values, or on custom code embedded in applications that depends directly on manually entered data
Manageability: There are three things here:
Auditability: Access decisions are often made inside applications that have variable amounts of logging of such decisions. This is true of both RBAC and ABAC systems. As a result, there is no central record of who requested access to what and whether and why such access was granted or denied. Even if collated from multiple apps, the policies that resulted in the access decision are impossible to identify
At the heart of the need to improve enterprise authorization are the issues of being coarse-grained, static, hard-to-manage, tightly-coupled inside applications and un-auditable. Any new technology that addresses enterprise authorization should be dynamic (i.e. based on continuously updated data), fine-grained and contextual to specific requests for access, consistent across all applications, easy to manage, and auditable.
Any new technology that addresses enterprise authorization should be dynamic (i.e. based on continuously updated data), fine-grained and contextual to specific requests for access, consistent across all applications, easy to manage, and auditable.
While ABAC can conceptually meet many of these requirements there are only a handful of solutions that fully realize the promise of ABAC. I propose that we need to come up with a new way to describe the next iteration of technology so, as an industry, we can distinguish between older, partial approaches and genuinely new techniques.
RBAC and ABAC are both functional descriptions of the authorization models. So it would be nice to have such a functional description of whatever follows. It would be nicer though, if the name describes the end-result instead, so that there is an in-built desired objective in it.
Vendors have attempted to call newer approaches with terms such as policy-based access control. This has the issue that it could mean anything, since ABAC (and even RBAC) is also “policy based”. Another term being used is NGAC (Next Generation Access Control) NGAC also is generic because it neither defines the model nor the outcome.
I like the term “Just-In-Time Access Management” (JITAM), as it describes what could solve these issues quite well. It describes the dynamism, i.e. access decisions must be made in real-time or near-real-time; And it describes the objective of manageability (not just control).
Want more of the latest identity-first security topics and trends delivered to your inbox? Helpful and insightful content, no fluff.