The Principle of Least Privileged Data Access
I love baking and take particular satisfaction out of leavening the dough. There’s something so exciting about returning to dough you’ve left to rise on its own and finding that it’s doubled in size! If only I could say the same for user privileges. While they too can bloat like dough, the outcome isn’t nearly as tasty — just risky.
Why do user privileges bloat?
Every organization delegates the role of assigning access privileges to at least one individual or team within the enterprise. It’s the responsibility of that person or team to process permission requests according to company policy and ultimately accept or reject them.
Granted vs Used Tables by Role
It’s very easy for granted requests to pile up when permissions are meted out in a role-specific manner instead of a user-specific manner. The reason for this is simple mathematics; it’s possible that only one or two people on a team is working on a project with that specific access need. Granting access to the entire team would therefore result in dozens of unnecessary permissions.This is often made worse by the fact that these processes are not always as documented as they should be, rendering it difficult to track the reasoning behind permission grantings down the line.
It doesn’t help that the requests almost universally move in one direction. You will rarely find a request from an individual asking for access removal. Users ask for access because they need it (or at least find the option attractive for potential uses down the line). This means that more privileges tend to be given than revoked, and users often have far more privileges than they actually need. This is problematic, as each additional privilege comes with additional risk of exposure.
Over-privileged users: the silent killer of security
Over-privileged users refers to those with more privileges than they need. This can either happen because they asked for privileges they don’t actually need, or because they “collected” and retained more and more privileges over time that are no longer relevant. Applications can also play a large role in this issue, such as when application credentials are copied to expedite the permissions granting of another application. Without focusing on the actual needs of the application in question, enterprises often end up granting them far more than they should actually have and turn them into growing risks over time.
This is why I consider over-privileged users and roles to be the silent killers of security. They become increasingly risky and it becomes a simple matter of time before they result in an unfortunate outcome. In the best case, this outcome can be a slap on the wrist after an audit. However, a data breach is far more likely.
Over-privileges in data access
This has become such a common issue in the world of data access for the following reasons:
Data moves, changes and grows. This means that, often, access that was granted once (especially to future tables) can end up containing more data than it used to. This is especially problematic when sensitive data is involved.
The people granting access to data are not always proficient in the kind of data stored or what users and applications do with data. This intimidates them away from changing access, lest they break or disrupt anything critical.
Enterprises are ever-changing. New teams form, new projects emerge and data scientists who used to work on certain data sets have moved onto others. A user from a certain team may move to another team but still own a project requiring their old access permissions. In other words, there are endless edge-cases as far as permissions go in your typical enterprise.
Over-privileges in Snowflake DB
Take the following example: here are some factors that contribute to over-privilege in Snowflake data warehouses:
Often, permissions are managed within the data warehouse by data engineering teams, rather than infosec teams, creating blurred ownership.
Snowflake allows for a role hierarchy, which may be a great tool for smart role management, but may also create visibility and manageability issues where roles are unintentionally granted permissions.
In many cases, teams or individuals request access to resources for a limited time to complete a project, but the permissions never end up getting revoked after they are no longer needed.
What’s the least privilege principle?
According to the least privilege principle, users should only have access to what they very specifically need. Anything more is considered excessive access. This principle reduces the risk posed by over-privileged users. As mentioned earlier, following through on this principle is no easy task and gets significantly harder over time.
How to Implement least privilege principles with Satori?
Permissions screen in Satori's management console
We identified the least privilege issue as a problem that many organizations face. We can help solve it in the following ways:
Satori analyzes the gaps between privileges (what users are entitled to use) and actual data access (what users are actually using). The gaps are then prioritized, so that action can be taken to eliminate non-requisite permissions and reduce the most risk in the shortest amount of time.
Satori customers can choose whether to remove permissions themselves or use Satori to streamline a process that ensures that permissions are not abused and represent the team's current access needs.
Satori analyzes gaps across different data stores via its reporting capabilities to ensure the holistic nature of its processes as well as ensure that they operate within the total context of the user’s needs.
If you’re interested in learning more about how Satori can help, please feel free to reach out!
Recent blog posts
- How to Control Access to PII in Snowflake with Satori
- Sensitive Data Isn’t The Crown Jewels
- Creating an Okta SSO application for a Satori-protected Snowflake account
- The Principle of Least Privileged Data Access
- The Do’s and Don’ts of Nailing that Developer Interview
- It’s Time to Set your Data Free (and Decouple it from Data Protection)