Todays’ IT and data infrastructures are highly distributed and spread across a vast, innumerable array of services, devices, applications, and users. With the advent of the cloud, traditional enterprise networks consisting of a physical firewall and data centers have given way to virtualized, highly decentralized architectures. Most internet users are unaware of the technical details and implications behind this shift to the cloud, even as they have become accustomed to ubiquitous access to IT and data resources. Crucially, the security mechanisms for authenticating and authorizing user access have also evolved to address these new models of computing, as security approaches of the past are increasingly ineffective at protecting against new cyber threats.
Because physical cybersecurity controls are no longer relevant in today and tomorrow’s cloud environments, new security models such as Zero Trust have emerged to address the risks involved in this new age of computing. Forward-thinking organizations no longer grant carte blanche access to IT or data resources once users get past traditional security measures like access control lists (ACL) and VPN. Per Zero Trust, all users are “untrusted” and considered malicious until authenticated and authorized; even then, they are granted just enough privileges for the task at hand.
Zero Trust requires organizations to adopt a more granular and resilient method of both authenticating users and authorizing them to access the required resources. Several Zero Trust-enabling access control security models have emerged over the past few years to meet the requirements of contemporary, cloud and virtualized environments. In this blog, we’ll cover the attribute-based and role-based security approaches to aligning with Zero Trust principles—namely, role-based access control (RBAC), attribute-based access control (ABAC), and policy-based access control (PBAC), and discuss their relative strengths and weaknesses.
Role-Based Access Control (RBAC) is an access control security model for restricting access to computer resources. RBAC is commonly found in most enterprise environments and uses a role-based framework defined by the business. In this model, roles are created, and then resource permission sets are assigned to each respective role. In turn, users are granted one or more roles to access resources. RBAC avoids assigning access permissions directly to users; instead, it bundles access permissions into assignments made to roles.
Because there are fewer assignments to be made, RBAC offers more centralized and streamlined security management capabilities; this makes for easier compliance auditing, as well as easier access maintenance and control and better continuous access visibility and visualization. Unfortunately, RBAC isn’t without its drawbacks—for example, the model is not suitable for making contextual, on-the-fly decisions, nor is it ideal for granular authorization requirements resulting in many roles.
In contrast to RBAC and its emphasis on roles, ABAC is focused on a subject/object’s assigned attributes, the environmental conditions, and policies designed to grant or deny access based on those attributes and conditions. These policies consist of rules that consider four attributes:
ABAC is considered more flexible to implement and somewhat simpler in nature, as it relies on access rules specified as simple queries. Since it evaluates both Subject and Resource attributes, it allows for more flexibility when creating and enforcing policies.
PBAC merges elements of RBAC with ABAC to overcome each of their respective limitations; some refer to it as a “relational” version of ABAC, since it grants rights to access and perform operations against resources/objects based on relationships (i.e., associations); this in turn enables the creation of complex, assignment-based policies that can be visualized and manipulated graphically. PBAC also enables organizations to implement and enforce dynamic segregation of duties (SOD) more easily—a feat difficult to accomplish with ABAC alone.
To identify which access control security model is right for your business depends on the organization in question; for example, RBAC can be simpler than ABAC to implement and may be ideal for smaller firms with limited resources. ABAC and PBAC allow for more fine-grained, dynamic authorization measures, at the cost of more complexity and implementation/maintenance overhead. For some firms, ABAC and PBAC’s improvements in security and compliance are hard requirements, as RBAC may not provide the same data access governance and authorization capabilities.
For Akoya, providing a best-in-class data infrastructure is critical to our goals as a company, and using a combination of access control security methods is instrumental to our layered security approach.
In response to requests from our data recipients, we are implementing RBAC within the Data Recipient Hub – the central touchpoint for data recipient customers. This will allow additional users to access the Hub for troubleshooting purposes without granting them administrative rights.
By following this common practice, multiple data recipients can leverage RBAC to enhance security controls for their teams. We will be granting two types of access to users: Admin and Viewer. Admin users will have comprehensive access to the Hub, including editing apps, clientID and Secret, and team management. Viewer users, on the other hand, will have limited access, restricted to viewing products, data elements, and data providers without the ability to modify any content.
To learn more about Akoya’s approach to security, please read our Zero Trust article and Security page, or contact us today for more information.