Evolving beyond RBAC: Why ABAC is the future

In the advent of a “work anywhere, anytime” environment, enterprises face a rapid expansion of diverse users alongside an influx of applications, devices, APIs and microservices. Additionally, the amount of data created and consumed by these users, devices and services continues to explode, creating extraordinary security and compliance challenges.

Formalized by NIST in 1992, role-based access control (RBAC) has long been a standard approach to managing access to critical assets and data, particularly for enterprises managing more than 500 employees. However, to ensure secure access, enterprises can no longer afford to define authorization policies based solely on a user’s role.

Axiomatics has identified four limitations to an RBAC-centric security approach and suggests enterprises evolve their RBAC model to an attribute-based access control (ABAC) model. ABAC is recognized by NIST as a model that can “improve information sharing within organizations and between organizations while maintaining control of that information,” and is at the core of modern security approaches, including zero trust.

Four RBAC limitations

• Role explosion: RBAC is limited to defining access permissions by role, however, as each user often requires entirely unique access rights, one user may be assigned several roles, creating a ‘one size fits all’ solution that can result in too much (or too little) access. This also makes enterprises vulnerable to an exponential rise in roles versus users.
• Toxic combinations: Various roles assigned to a given user could contain conflicting data (i.e., someone is assigned a role allowing them to create a purchase order and another allowing them to approve the same order). This poses a significant business risk if not managed properly.
• Management nightmares: With an exponential growth of both users and roles, role engineering is a challenge. Administrators must constantly be aware of changes to both users and roles to ensure role assignment combinations are current, accurate and do not conflict with other roles a user is assigned.
• No context: RBAC was designed to be static, meaning it does not model policies that depend on contextual details including time of day, location, relationship between users, relationship between users and resources, etc. It was designed to address user access based on assigned role. Expanding user populations (including partners, consumers, regulators and auditors) and multi-role users requires authorization based on a finer level of information.

ABAC is the future of access control

• Roles are still – and always will be – an integral part of a successful access control strategy, but to address critical enterprise needs (complex regulatory requirements, scalability, remote workforces) these roles must be extended using attributes and policies derived through ABAC.
• ABAC adds context, ensuring authorization decisions can be made not only on a user’s role, but also by considering who or what that user is related to, what that user needs access to, where that user needs access from, when that user needs access, and how that user is accessing the requested information.

Dr. Srijith Nair, Chief Strategy Officer, Axiomatics: “Whether it’s zero trust or another approach, more enterprises understand that a modern workforce requires a modern approach to security, which means evolving beyond RBAC. Modern data sharing and collaboration scenarios must provide access to the right user, at the right time, in the right location, and by meeting regulatory compliance.

“By evolving RBAC with ABAC, administrators provide well-rounded access control that builds on RBAC while harnessing ABAC’s context to address today’s requirements and future needs.”

from Help Net Security https://ift.tt/3F5rflB

Related Items