If you haven’t implemented policy-based access control (PBAC) yet, now is the time. Here’s why.
Enterprise network users are increasingly located off-premises, connecting via the public Internet or mobile devices. More and more corporate data and applications reside in the cloud instead of on-premise data centers as companies adopt IaaS and SaaS solutions. There is no longer any separation between inside and outside a network perimeter, and the perimeter itself is porous. Factor in the Internet of Things (IoT), and there’s really no perimeter at all.
At the same time, collaboration and the exchange of data between departments; throughout remote company locations; and among employees, vendors, partners and others, is essential to keeping businesses operating. Everybody needs to access data.
Everybody needs to share data. But not everybody should have access to or be able to share every piece of data. And the criteria that determines the who, what, why, when and how of data access is constantly changing as business requirements change, roles fluctuate, new company locations get added or removed, and other factors come into play. Decisions regarding data access need to be made at the time of access, based on the situation.
Not surprisingly, current IAM solutions can’t get the job done. There’s too much data, too many access points, too many identities, roles and attributes to be managed and updated. Too many variables.
The use of RBAC and ABAC made sense at one time but, as discussed in a previous blog, both have inherent disadvantages that make them cumbersome and ineffective for use in today’s rapidly changing business world. They lack scalability, are resource-intensive, and can’t successfully function without well-defined network perimeters. They also can’t meet increasingly rigorous governance requirements.
If your organization is to remain competitive in this fast-changing business landscape, it must have the mechanisms in place to ensure all essential data is available to whoever needs it, whenever they need it and wherever they need it — but that the data remains safe and only accessible to who you authorize, when and where you authorize that access.
PBAC meets that criteria and provides even more benefits. It solves the deficiencies of RBAC and ABAC. It builds upon existing IAM and employs context-based security policies that allow for both scalability and agility, along with the standardization of aspects of the ABAC model that enable it to support specific governance objectives.
It’s also easy to implement. For one thing, there’s no need to clear repositories. Nor do you have to redefine roles and attributes. You can build up the authorization controls you already have in place, and continue enhancing them.
To get started, follow these three steps:
This is all the data you currently use to make authorization decisions, as well as any you need to add. Typically, this will include:
-Identities – These are the user attributes, security roles and other information that define the various users who need to access data. What are identities you are currently using and what information do you have on them? Are you using existing roles? Are any attributes used? Are there others you need to add? Consider all the various sources from which you can pull information about the identities that will be used in your policies, such as Human Resources, training system, project management, etc.
-Authorization data – This is the criteria used by all the various applications within your organization that determine whether to permit access and what actions users can perform with that data. Authorization data can also be represented by the digital assets you want to protect, and their associated actions.
-Environmental data – This includes things like location, time, authentication level, events, and other criteria that can affect access decisions. As you go through the rest of the process of assembling your PBAC building blocks, you can always add to or update this information.
You already have numerous existing policies that affect data access. Collect them all. Reach out to your stakeholders for assistance in gathering any that they may use or know about. You can use a policy mining tool to help uncover everything you have, as well as to display and evaluate any suggested policies.
Once you have some of the policies, you can start assessing and verifying them. You can also modify them or create new ones. For both existing and new policies, consider any contextual factors that could or should determine access decisions.
Test the policies to ensure they work as expected for both runtime and admin-time authorization decisions. Use a policy testing tool, that provides a wide picture from identities to application, an end-to-end view of the policy impact. Validate them with your stakeholders. Again, consider all scenarios. You want as broad of a picture as possible of your access policies and their effectiveness before moving forward.
Done. Now you have your policies. The next step is to start enforcing using those policies, which is even easier. Stay tuned for a future blog that will help walk you through that process.