In a changed and changing world where network defenses have disintegrated, policy has become the new perimeter. We protect the assets we value–data, services, resources, workloads–by granting or denying access to them. If you rely on role-based access controls (RBAC) to govern access, you may think you’re already doing it right, but it’s more important than ever to examine your assumptions, because the standards themselves–and the available technology to implement them–have changed.
In this seven-part series, I’ll trace the evolution of access controls, pinpoint the shortcomings of RBAC, define attribute-based access controls (ABAC), contrast ABAC to other approaches, discuss what use cases it enables, investigate the perceived risks of an attribute-focused approach, and finally, close with the most effective way to implement ABAC into your organization.
Tracing the Evolution of Access Controls
The dawn of the digital age led to the creation of discretionary and mandatory access control models, governed by either the user or the system administrator, respectively. These early access control concepts were replaced by identity-based controls that leveraged access control lists (ACLs). If the subject requesting access had a credential that matched the ACL defined for the object, then she would be granted access to perform an operation, like read, write, edit, execute, modify, copy, or delete. These models were template-based and static–every object needed its own ACL–and they led to overprivileging, or granting access more broadly to actually allow users to get their jobs done.
The rise of identity and access management (IAM) solutions began with thick client access controls tightly coupled with a single static view of an organization. Whenever a user joined the company or changed roles, her access credentials would need to be updated in a myriad of locations to affect every application she might need. Identity solutions evolved to reference less static information stores like active directories and assign privileges to roles, instead of the users themselves.
The concept of federated identity–where a single identity store could be used to govern access within multiple applications–was a quantum leap. I remember the time when I gradually relinquished my individual login and password combos in favor of single sign-on (SSO) credentials. I cheered! Since then, identity access control models have begun moving from on-premises solutions, like a Lotus identity stack, to cloud-based solutions like Okta or Ping. They have begun layering tokenless multi-factor capabilities like Duo as added security measures.
And yet they still depend on role-based access controls.
Part 1/7 ABAC Blog Series: Policy is the New Perimeter