Least Privilege is at first glance obvious and self defining. It means only giving users the access they actually need to perform a particular task in a system. On its face, it seems like you would never give users more privileges than they need so it should be something we do by default all the time.
Examples where we apply least privilege include:
In practice, applying least privilege can be difficult for a couple of reasons.
Consider an app like Zoom, which for user convenience bent security norms by installing a web server to self update and used more open privacy defaults than we may have expected. In today’s world, many of these decisions are why Zoom is so widely used, but at the exact same time the look like significant issues to security folks. In this case, if Zoom were more aggressive about applying least privilege, they might have lower user adoption.
At a programming level, one of the challenges we face is walking the balance between a very fine grained privilege model where each and every capability is provided on a case by case basis and a coarse grained model where these capabilities are aggregated into just a few roles.
Other good examples are the Serverless framework and AlgoVPN in AWS. If you follow the easy mode instructions for these tools, you will create admin level credentials to create the resources you need in AWS and often, if you are not careful, end up running the tools with these same admin credentials which can create and destroy all sorts of resources in AWS. Really what we want is a provision mode level of privileges and then a run mode level of privileges that uses the resources provisioned but cannot create new ones.
Being mindful of least privilege can help us to keep data secure. We can do that in:
Ultimately, like with most application security topics, we have to understand what our system is doing, what our roles mean and where those intersections work to implement a coherent least privilege model.