Imagine you’re in the midst of a brand-new data governance project. You’ve done your data discovery and classification – you know where your sensitive data is. Now you just have to write the policies that determine who gets access to it. But how should you approach setting up those permissions? This blog will walk you through considerations for RBAC vs ABAC vs PBAC. If you already know what those mean, great. If not, don't worry, we'll explain.
Let's Start with RBAC or Role-Based Access Control
Starting with marketing, you think, “Marketing sends emails to customers, so they need access to customer information.” It just makes sense, right? This would be “role-based access control” (RBAC) – users get access to data based on their spot in the company org chart.
But if you start to dig deeper, it gets more complicated – does the VP of brand need customer email access? Does a copywriter? Unless you’re actually in marketing – or product development or finance – it can be difficult to know what roles actually need access to specific sensitive data in order to do their jobs. Does everyone in finance need access to all the financial information? Does a UX Designer in the product team need access to all the technical product specs? People on the same teams can have very different jobs and need very different tools and access. And, if people have access to sensitive data that’s not essential to their jobs, it just increases the risk of potential theft or loss.
How could you find out who needs what? Do a survey or reach out to each individual to ask? Or work with the department head who may not even know exactly what each person needs? Now that can get really time consuming. Let's take a look at some other approaches - RBAC vs PBAC vs ABAC - and don't worry, we'll explain each.
Asking “Why” Leads to "PBAC" or Purpose-Based Access Control
You could go ahead and set up your role-based access controls – give access to the marketing team – and then see what happens. See who uses what data, when and how much. And then you can ask the most important question: why? You can get very targeted about why a user is accessing certain data at certain times. Maybe the Marketing Ops Specialist is accessing 3,000 customer emails on Thursdays to send out a coupon for the weekend. Not only does watching consumption allow you to narrow in on the data being accessed, but it also acts as a source of truth. Instead of relying on people to accurately tell you what data they need, you can see what data they’re actually using.
Once you understand the reason the data is being accessed and agree that this is an acceptable business usage, you can put policies in place that only allow this data to be accessed by this user at this time in this amount. We call this purpose-based access control. Your policies are no longer about whether someone is “on the marketing team”, but rather “this person needs to send emails for the marketing team.”
PBAC vs "ABAC" or Attribute-Based Access Control
Purpose-based access control might be considered a form of “attribute-based access control” (ABAC) where the attribute is simply “purpose.” Focusing just on purpose has a few advantages over full-fledged ABAC though: first, it’s significantly less complicated and it’s much more accurate. Instead of setting up and maintaining thousands of attributes about the user, the data, the activity, and the context, you’re just focusing on the one that really matters: why the data is needed. And since it’s based on real consumption information, there is no guessing who might need what when or where. Instead of trying to write rules for a limitless number of contingencies, purpose-based access control narrows in on actual data usage and need.
This leads to another key advantage: if you know “why” someone needs the data, you also know “how much” they need. Going back to our marketing email example, you can look at the pattern of consumption over the last few weeks and find that they generally only send out about 3,000 emails each time. It would be out of the ordinary to send 10,000. So, you can set up your “this person sends marketing emails” purpose-based policy to have a limit of 3,000 at a time, only on Thursdays. If they need to do something out of the norm, they can ask for that permission. Setting thresholds like this protects privacy and reduces the potential for unintentional data leaks or credentialed access theft.
Knowing “why” also puts you better in line with privacy regulations that require companies to not only provide what data they store on people, but also for what purpose. Having that information at your fingertips makes it easier to comply with the law.
Finally, because it’s based on just one variable – does this person need to do this activity – it’s much simpler to automate approvals and access when a new person joins the team or if the activity shifts to another team member.
Build Purpose-Fit Policies by Watching Consumption from the Start
Now imagine you had included watching consumption as part of your data discovery and classification project – as you were finding sensitive data, you were also finding out how it was being used. Maybe marketing isn’t the only group using marketing data. You would have a true-to-life map of data usage throughout the company, you could build your purpose-based access controls right the first time based on real need, and you would spend less time adjusting policies, making exceptions, and tightening access.
Purpose-based access control is as simple as RBAC in that it focuses on just one variable, yet it can be a better fit to your org because it’s based on how data is actually used, it’s simpler to automate, and it reduces risk by limiting access to a narrow amount of data only to those who need it for a specific purpose.
Now, the next question is, “Why aren’t you doing this already?”
.png)
.png)
.png)
.png)
