Legacy RBAC systems rely on static user identities. Each job function may have a corresponding role that will always have permission to access the same resources. The hardware’s capabilities limit on-premises infrastructure. An on-premises server has a limited amount of memory, and stored applications rarely change, creating static role-based identities.
For example, anyone with the role of “manager” can always edit data. However, digital transformation lacks that limitation. Organizations use cloud-based infrastructures because they scale based on your needs at the time. If you need additional storage or expect further activity, you can increase your cloud usage for a short period. Identity in a modernized infrastructure needs to be dynamic because the infrastructure is dynamic.
Introducing Attribute-based access controls (ABAC)
Attribute-based access controls (ABAC) help you to create detailed access definitions that link a user’s role to context, such as resources, IT environment, or user location. Detailed privileges, also called “fine-grained entitlements,” create multi-dimensional access controls that go beyond application access and define the accessible resources within the application.
RBAC appears to mitigate access risk by limiting access. In many cases, users may hold multiple roles, and as the organization adds more cloud-based resources and is more agile, IT admins will struggle to update role-based access needs continuously. Users will request additional access since their roles do not allow them to access needed resources. When admins cannot map pre-defined roles to the required resource, they must create new roles. However, these often cannot continuously monitor access requests that maintain the “least privilege.” Since roles focus on generalizations, organizations either create roles with too much access or too many roles to monitor appropriately, leading to privacy risk.
With attribute-based access controls (ABAC), you create a central identity governance and access administration policy that focuses on attributes and context. This can include user job function or time of day and resource attribute, object, or environment. Using ABAC within complex on-premises, hybrid, and cloud-based infrastructures allows you to establish an “if, then” approach to providing access to resources within your ecosystem. Unlike RBAC, which uses generalizations to grant access, ABAC allows you to create sophisticated restrictions that improve data privacy.
For example, an “HR Manager” role might be able to access everything within your human resources application. A “Marketing Manager” role should only access information about the people in that department. However, both managers may need “Training Manager” roles to access a cybersecurity training application. Using RBAC requires ensuring that each user has multiple roles and the roles have the correct entitlements; it can quickly become challenging to manage.
On the other hand, ABAC allows you to restrict access and grant access on a more detailed level. With ABAC, you can use “if/then” statements that define how users interact with resources. Instead of giving a user multiple roles, you can tie access to a resource to an attribute value. For example, “If user’s <department> is HR, grant access to the HR Application.” You can also create broader definitions for the HR Manager users, such as “If user’s <title> is Manager, grant access to all HR, Training Application, and Payroll Application.” Two defined sets of attributes now grant the appropriate level of access to sensitive information.