The principle of least privilege holds that a user or application should have only the privileges necessary to do their job – and nothing more. This principle is one of the key tenets of access control, providing high level guidance on who should be allowed to access what at an organization.
The principle of least privilege mitigates risk: the fewer people who have access to sensitive data, the lower the risk that information could be stolen, leaked, or damaged.
Some organizations, especially those protecting sensitive assets, will want to hold to the principle of least privilege as strictly as possible. Other organizations might instead opt for a culture of transparency, in which information and resources are accessible by default – while still protecting sensitive data and resources.
The Principle of Least Privilege in Practice
Depending on its implementation, the principle of least privilege can be an administrative control or a technical one. If it’s set forward through company policy, it would be an administrative control. If it’s implemented through computer systems, it would be a technical control. Often, the principle of least privilege involves a combination of both.
The principle of least privilege is highly dependent on how granular you want to get. In its strictest implementation, access is revoked immediately after a user no longer needs a resource. You might even require a user to file why they need access every time they access a sensitive resource. This approach makes sense to protect highly sensitive assets, but this level of strict, granular access control isn’t the best approach in every context. It wouldn’t make sense to make employees explain themselves every time they enter the workplace, for instance.
Oftentimes, the principle of least privilege is more a north star guideline than a strictly implemented rule.
Under Windows, for instance, most applications operate with limited privileges unless a user runs them as an administrator. Under normal usage, an application can modify files on the computer, but not the operating system itself or its security settings.
This isn’t a strict implementation of the principle of least privilege – that would mean limiting the application’s behavior much more tightly – but in limiting access to the most sensitive areas of a computer, the system follows the principle of least privilege more closely than if access were unlimited.
Many organizations opt for a culture of transparency, under which access is open by default. A marketing employee can access the sales team’s data, for example. That information isn’t strictly necessary for the marketing employee to do their job, but it can inform their decision-making – and requiring them to jump through hoops to get it would only discourage them from seeking that information.
Even in more open organizations, certain data and resources demand protection. When it comes to customer data or access to the company’s bank account, it makes sense to limit who has access. But when it comes to other information and resources, adhering to the strictest implementation of the principle of least privilege can be limiting.
The downside of transparency is risk. The more people that have access to something, the greater the risk it could be stolen, leaked, or damaged. You might not need to carefully guard who can use the copy machine – but the more people who use it, the more people who might spill coffee on it. That’s a risk you might have to accept so that people can copy and scan documents without going through an intermediary.
It comes down to the organization to determine how strictly to adhere to the principle of least privilege. In any case, it’s a very useful guideline that should inform your approach to access control.