Policy-driven Authorization
Traditionally, policies have been considered from a role-based approach, which continues to cause issues for enterprises. It’s time to rethink policies for the modern cybersecurity landscape to reduce risks to enterprises.
Get a demoIt’s time to rethink your approach to policy
Governing access based on a role has been the typical practice up until now.
IT would assign a user to a role and policies would be established to clearly state what a specific role could access or do.
This approach became a prominent methodology in 1992, over thirty years ago, but many enterprises still lean on a role-based access control (RBAC) approach to determine policies.
This results in many challenges including: role explosion, conflicting policies, and policies not always aligning to business requirements.
How do we rethink policies?
Organizations’ needs are constantly changing, so are the policies that govern access control. Many organizations are still thinking about roles, which has some advantages, but basing policies solely on roles does not address the modern cybersecurity landscape.
This leaves enterprises open to risk as role-based access control (RBAC) does not address the complexity required by organizations to deliver the best experience with right-sized access for every user.
Policies can be rethought by adding in the fine-grained elements from attribute-based access control (ABAC). Access control strategies that leverage attributes to define detailed access policies enables organizations to align to complex and ever-changing security and compliance requirements.
This allows you to extend your RBAC strategy by considering other attributes in addition to roles.
Users can be granted or denied access based on a combination of attributes making access decisions more precise than traditional methods.
Creating policy-driven authorization
| Consider the business outcomes | Write in plain English | Reconsider the ownership model |
|---|---|---|
Start by asking some essential questions, which may include:
Example: an organization wants to let its users access records easily, but recognizes the need to differentiate required access for employees versus customers versus partners, etc. | Write down what you want to achieve with the policy in plain English. This moves away from the thought process of RBAC where one is only considering roles and not other attributes. This is important because it closes the cognitive gap of some languages. When forming the authorization requirements, it is important to not do a role engineering exercise – writing policies requires a different thought process when compared to roles. | Who owns the policy conversation varies from enterprise to enterprise. The truth is that there is no one team that should own policy. Critical stakeholders should include: development team, identity/security team(s) and business/application owners. This might lend itself nicely to a DevSecOps model whereby a core team representing each of these groups comes together to ensure policies and procedures satisfy all stakeholders while achieving the main goal – solving for critical business outcomes. |
Let's show you a demo and take the next leap in your authorization journey
Meet with us and see how our award-winning solution can help you meet today's access control and Zero Trust needs.
Request a demo