When safeguarding sensitive data, sometimes the simplest actions can be a major help. While you should definitely create a multi-layered security policy for your database that uses the right tools, the wall you’re building is best maintained by users and administrators who follow some basic security rules.
One of the most critical ones is the Principle of Least Privilege (or PoLP). By adhering to this principle, your organization can save time, money, and energy reducing risk to the database but avoiding data falling into the wrong hands entirely.
In this article, you will learn about:
What is the Principle of Least Privilege (PoLP)?
The Principle of Least Privilege (also called the “Principle of Least Authority” or “Principle of Minimal Privilege”) is exactly what it sounds like: it’s the practice of granting the least amount of privileges to users in order for them to do their jobs within the database.
This means that only administrators have administrative access and acknowledging that the sales intern doesn’t need the power to delete entire tables within the database. Indeed, every user is assigned just enough access and privileges to the database to do their jobs effectively and nothing more.
The Principle of Least Privilege is especially important when determining levels of access based on organizational hierarchy, performing security and privilege audits, and minimizing risk of bad actors getting access to critical systems within the database. After all, your administrators should know how to create strong passwords; the sales intern with the over-privileged account probably doesn’t.
Need to Know vs. Least Privilege
When discussing the Principle of Least Privilege, people might misconstrue the idea of “least privilege” with a term called “need to know.” While the two are correlated, they are not as interchangeable as one would think.
“Least privilege” refers to a user’s ability to access data, but also write, edit, or delete it. For instance, the lead account executive might have access to every client record with the ability to add, change, or remove any of those records.
“Need to know,” however, refers to a user’s ability to access data with the purpose of only viewing it and only when this is part of their role or requirement for their work. A junior account executive might be able to change the records of clients they directly work with, but can only see the client records of others on their team – and of that, only select information. It might be helpful for people in the same sales team to see who’s been assigned to which clients. But being able to change co-workers’ records unilaterally isn’t the best policy.
Why is the Principle of Least Privilege Important?
In addition to increasing database security at the system level, the Principle of Least Privilege has a few other benefits. One such benefit is minimizing the risk of human error (or even maliciousness).
Again, the whole point of this principle is to assign privilege to those who are skilled enough to use it effectively. By only assigning administrative access to a very small group of people who know what they’re doing, if there are any errors, it’s easier to find where they’re happening. This makes audits much easier if you have thousands of database users but only five have the ability to cause the error at the access level they had.
Moreover, adhering to PoLP minimizes an issue called “privilege creep.” This is when a database user is given more access over time (perhaps due to promotions or other changes in their role) but their old privileges that are now irrelevant weren’t revoked.
At both the user and application level, using PoLP speeds up deployment as the fewer privileges users or different applications or plugins require, the easier it is to set them up and secure them.
Principle of Least Privilege Examples and Use Cases
Example 1: Database User Changes Roles in Your Organization
Each department head in your organization has write and edit privileges for every piece of information related to their department. The VP of Marketing recently was moved over into the VP of Sales position, overseeing new teams and new tables of sensitive data.
The Principle of Least Privilege dictates that this person should have their old access related to their marketing activities revoked when switched over to the sales-related data.
Example 2: Interim Sales Manager Needs More Access
After losing a sales manager, someone on the sales team is put in the position until a new sales manager is named. The acting sales manager is given additional access to fulfill their duties in the interim period. Once a new sales manager is named, the acting sales manager has those privileges revoked – unless, of course, they were promoted into that position.
Principle of Least Privilege Best Practices
Though the Principle of Least Privilege is a straightforward concept, there are a number of best practices to consider to make the most of it.
Keep User Privileges and Access Updated
The easiest way to combat privilege-related risk is by keeping user privileges and access as up-to-date as possible. Whenever there are any promotions, role changes, or layoffs, database access should be changed immediately. The longer it takes to change privileges, the longer you leave the window open for bad actors to take advantage of this oversight.
Implement Temporary Privilege Escalation
Privilege creep comes from not removing privileges from those who no longer need it. A simple way to keep this from happening is by using temporary privilege escalation. In other words, if someone has a reasonable need to make an action above what their usual role requires (for instance, the sales manager is out on vacation for a long weekend), granting someone temporary privileges and removing them as soon as they’re done keeps the work process moving forward without unnecessary risks to data security.
Apply RBAC and ABAC When Needed
Two kinds of access controls you can implement alongside the Principle of Least Privilege are role-based access control (or RBAC) and attribute-based access control (or ABAC).
RBAC refers to many of the examples we’ve used so far: it’s authorization and access control based on the roles one has within your organization and their need to access information related to those roles. Most of RBAC is determined by the database administrator and those who determine the organizational hierarchy, the roles within it, and the functions of those roles.
ABAC is much more granular. Not only does it refer to a user’s organizational roles, but it can take into account other attributes such as times data is accessed, location of the data, the location of the user accessing the data (i.e. what machine and its relevant IP information), when the data was created or last modified, etc.
For a comparison between the two, go to our RBAC vs. ABAC page.
For some organizations, RBAC is enough, but for those who require a more granular control over their data, an ABAC configuration would be the way to go. If you prefer having more control of your database’s security and can invest the time to set it up – or compliance regulations compel you to have additional security measures – ABAC should be your organization’s choice for fine-grain security.
Implementing Principle of Least Privilege with Satori
Satori helps you ensure a simple and secure data access. As part of this, Satori simplifies access control across all your data stores. This enables temporary access workflows and self-service access elevation.