Principle of Least Privilege

two pink padlock on pink surface

The Principle of Least Privilege (POLP) states that any identity in your system should have the minimum required access rights to perform a specific task. POLP applies equally to people and systems; your systems should have the minimum rights necessary.

As time passes, certain identities tend to gather more permissions. This phenomenon is called “privilege creep”, and we need to counteract it through analysis and auditing. A common method is the temporary increase in permissions, provided only for the time necessary to finish a task; this is called “privilege bracketing”.

Imagine for example that you have a typical web application used by multiple external users, and connected to a database. According to the principle of least privilege, the web application should connect to the database using different users depending on the types of tasks it attempts. For example, you would need a number of users only allowed to:

  • read common data (eg. UI localization database, catalogs etc.)
  • read data from one identity in your web application, except sensible information such as account or authentication information
  • read sensible information for one identity in your web application
  • modify or add sensible information for one identity
  • modify or add data for one identity other than sensible data
  • modify or add common data
  • read administrative data such as lists of users
  • perform administrative tasks such as initiating a password reset

Once you have all these different accounts set properly, the next weak link in the chain becomes the configuration files. At least ensure that the database connection string is encrypted, or even better read from a protected vault.

When deciding on the permissions you will probably need to make trade-offs between the number of users and other factors such as performance, scalability or reliability.

This analysis only applies to database access, but what about system access? You will need to make a similar analysis for SSH keys, OS users etc. Then, what about physical access to systems? Can someone inject malware using USB ports on your servers or through the laptops of your senior programmers with access to servers?

In addition to this, you will need to ensure access logging, access monitoring including alarms in case of surprising usage patterns etc.

While tedious and potentially introducing complexity in your code, the POLP helps you reduce a lot the potential for attacks. If the database user has only the permissions to do the same things that the application user can, then attacks such as SQL Injection even when successful have little to no effect. In case of a successful breach, the attacker would have to find ways to exploit database engine vulnerabilities to gain access to other user’s data, which increases the potential to be blocked or even identified.

Scroll to Top