How to implement least privilege in the cloud
According to a recent survey of 241 industry experts conducted by the Cloud Security Alliance (CSA), misconfiguration of cloud resources is a leading cause of data breaches.
The primary reason for this risk? Managing identities and their privileges in the cloud is extremely challenging because the scale is so large. It extends beyond just human user identities to devices, applications and services. Due to this complexity, many organizations get it wrong.
The problem becomes increasingly acute over time, as organizations expand their cloud footprint without establishing the capability to effectively assign and manage permissions. As a result, users and applications tend to accumulate permissions that far exceed technical and business requirements, creating a large permissions gap.
Consider the example of the U.S. Defense Department, which exposed access to military databases containing at least 1.8 billion internet posts scraped from social media, news sites, forums and other publicly available websites by CENTCOM and PACOM, two Pentagon unified combatant commands charged with US military operations across the Middle East, Asia, and the South Pacific. It configured three Amazon Web Services S3 cloud storage buckets to allow any AWS global authenticated user to browse and download the contents; AWS accounts of this type can be acquired with a free sign-up.
Focus on permissions
To mitigate risks associated with the abuse of identities in the cloud, organizations are trying to enforce the principle of least privilege. Ideally, every user or application should be limited to the exact permissions required.
In theory, this process should be straightforward. The first step is to understand which permissions a given user or application has been assigned. Next, an inventory of those permissions actually being used should be conducted. Comparing the two reveals the permission gap, namely which permissions should be retained and which should be modified or removed.
This can be accomplished in several ways. The permissions deemed excessive can be removed or monitored and alerted on. By continually re-examining the environment and removing unused permissions, an organization can achieve least privilege in the cloud over time.
However, the effort required to determine the precise permissions necessary for each application in a complex cloud environment can be both labor intensive and prohibitively expensive.
Understand native IAM controls
Let’s look at AWS, since it is the most popular cloud platform and offers one of the most granular Identity and Access Management (IAM) systems available. AWS IAM is a powerful tool that allows administrators to securely configure access to AWS cloud resources. With over 2,500 permissions (and counting), IAM gives users fine-grained control over which actions can be performed on a given resource in AWS.
Not surprisingly, this degree of control introduces an equal (some might say greater) level of complexity for developers and DevOps teams.
In AWS, roles are used as machine identities. To grant an application-specific permission requires attaching access policies to the relevant role. These can be managed policies, created by the cloud service provider (CSP), or inline policies, created by the AWS customer.
Reign in roles
Roles, which can be assigned more than one access policy or serve more than one application, make the journey to least-privilege more challenging.
Here are several scenarios that illustrate this point.
1. Single application – single role: where an application uses a role with different managed and inline policies, granting privileges to access Amazon ElastiCache, RDS, DynamoDB, and S3 services. How do we know which permissions are actually being used? And once we do, how do we right-size the role? Do we replace managed policies with inline ones? Do we edit existing inline policies? Do we create new policies of our own?
2. Two applications – single role: where two different applications share the same role. Let’s assume that this role has access permissions to Amazon ElastiCache, RDS, DynamoDB and S3 services. But while the first application is using RDS and ElastiCache services, the second is using ElastiCache, DynamoDB, and S3. Therefore, to achieve least-privilege the correct action would be role splitting, and not simply role right-sizing. In this case, role-splitting would be followed by role right-sizing, as a second step.
3. Role chaining occurs when an application uses a role that does not have any sensitive permissions, but this role has the permission to assume a different, more privileged role. If the more privileged role has permission to access a variety of services like Amazon ElastiCache, RDS, DynamoDB, and S3, how do we know which services are actually being used by the original application? And how do we restrict the application’s permissions without disrupting other applications that might also be using the second, more privileged role?
One native AWS tool called Access Advisor allows administrators to investigate the list of services accessed by a given role and verify how it is being used. However, relying solely on Access Advisor does not connect the dots between access permissions and individual resources required to address many policy decisions. To do that, it’s necessary to dig deep into the CloudTrail logs, as well as the compute management infrastructure.
Least privilege in the cloud
Finally, keep in mind that we have only touched on native AWS IAM access controls. There are several additional issues to be considered when mapping access permissions to resources, including indirect access (via secrets stored in Key Management Systems and Secret Stores), or application-level access. That is a discussion for another day.
As we’ve seen, enforcing least privilege in the cloud to minimize access risks that lead to data breaches or service interruption can be manually unfeasible for many organizations. New technologies are emerging to bridge this governance gap by using software to automate the monitoring, assessment and right sizing of access permissions across all identities – users, devices, applications, etc. – in order to eliminate risk.