Skip to main content

Applying the principle of least privilege to cloud infrastructure

(Image credit: Image Credit: Melpomene / Shutterstock)

The principle of least privilege is one of the most fundamental and important concepts in cloud infrastructure security. The principle of least privilege for cloud infrastructure states that only the minimum access necessary to perform an operation should be granted to all identities (human or non-human) accessing multi-cloud or hybrid cloud infrastructure, and that access should be granted only for the minimum amount of time necessary. It is this concept of time and the principle of limiting access to only when it has required that is most frequently forgotten and the most difficult to implement in a dynamic, complex multi-cloud environment. 

The Principle of Least Privilege is quite often seen as the holy grail — everyone wants it, but everybody has a difficult time implementing it, including organisations with the most mature security programs. This is due to the effort and complexity involved in implementing this concept across a dynamic cloud infrastructure. 

Additionally, end-users usually hate it because of the perception that they will no longer be authorised to access certain non-essential infrastructure resources and applications. However, auditors and compliance managers view it as essential to the success of an organisation with a limited understanding of how hard it is achieved within any complex organisation. 

The benefits of implementing the principle of least privilege are readily apparent to all security practitioners:

  • minimising potential attack surface - particularly the insider threat surface
  • increasing regulatory compliance
  • better cloud infrastructure stability
  • limiting the damage that can result from accidents, errors, or compromised credentials

Determining least privileges for cloud infrastructure identities is complex and hard

The idea of figuring out the least privileges for every digital identity (machine and/or human) accessing cloud infrastructure is pretty easy to understand and sounds pretty simple to implement: just make sure you only give privileges or permissions to those identities that need it to perform their job — right? Unfortunately, determining what privileges or permissions are needed for each identity or a set of identities is one of the most difficult tasks in cloud infrastructure security, let alone doing it at scale across an organisation with a multi-cloud or hybrid cloud environment with years of privilege creep. 

Let us explore this in more depth for a minute — how do you know when an identity needs the privileges or permissions to perform a certain job?

  • Is it because they tell you they need it? This is most definitely not the case — for obvious reasons.
  • Is it when someone is approved to have it? Does it matter who approved it? And what if that approval was 2 years ago or only made to perform one task — unfortunately, privileges accumulate and change over time without the proper management and needs change over time too.
  • Should the privileges or permissions be associated with a subset of resources?
  • What about if they have never used it or only used it once? Is it still needed?
  • What about if they need it once a year or only in an emergency?
  • What if another separate identity (human or non-human) performed the job instead?

It is indeed very challenging and difficult to figure out a definitive measure of least privilege, particularly when you consider time in the equation.

Treating least privilege as a process

Consider implementing the principle of least privilege across your cloud infrastructure as a continuous process. First, get visibility into how permissions are being used. Second, determine what additional permissions are needed to perform an operation on a specific resource and grant them on request to get the job done before revoking the permissions. 

This should sound familiar when you consider the forgotten principle of limiting least privilege to only when required. This dynamic approach will, by necessity, require steps to: 

  • Have a single method of getting visibility of permissions across all your cloud infrastructure, in particular across any and all AWS, GCP, Azure and vSphere deployments in your organisation.
  • Monitor what permissions are being used or attempted to be used and what resources they are used on by comparing logs and identity activity to permissions and figuring out what permissions are regularly used and when.
  • Remove any inactive identities or remove any associated permissions from those identities that have not been utilised over a period of 90 or 180 days.
  • Identify permissions that are only needed for short periods of time and implement workflow and automation to provision these permissions for only the time period required.
  • Remove unused permissions from all other identities that have not been utilised for an extended period of time.
  • Implement on-demand or just-in-time processes to rapidly (and potentially through a self-service model) elevate permissions or privileges on specific cloud infrastructure resources where required to reduce the impact of restricted privileges.
  • Investigate any abnormal activities by identities, and particularly unusual usage or attempted usage of privileges and -- where possible — auto remediate.
  • Ensure continuous compliance controls are in place across all of the different cloud infrastructures in use across the enterprise.
  • Leverage best practices for permissions management across the organisation’s multi-cloud or hybrid-cloud infrastructure.

Ideally, through the ongoing changes envisaged by these processes, you will continually reduce permanent permissions assigned to both human and machine identities over time. Regardless of whether you adopt a more dynamic approach to implementing least privilege as a process, it is very critical for all organisations leveraging multi-cloud or hybrid-cloud infrastructure to implement the principle of least privilege. 

The key to getting the basics right is “right-sizing” permissions and focusing on the permissions that an identity requires based on what they require to do their job on a daily basis compared to identifying all the permissions they might possibly need at any point in time. Augment this with delivering any additional permissions or privileges on demand when and only when identities need them. This delivers a comprehensive authorisation model based on permissions used as opposed to permissions granted – and brings the holy grail within reach.

Raj Mallempati, COO, CloudKnox Security