7 Steps to Avoid the Top Cloud Access Risks

According to the latest Cloud Security Alliance (CSA) report on the 11 biggest threats to cloud computing, misconfiguration and inadequate change control ranked second only to — you guessed it — data breaches.

The Capital One incident, in which data on 106 million credit card customers and applicants was exposed, is a good example. The attackers exploited a vulnerability in an open source web application firewall (WAF) that was being used as part of the bank's cloud-based operations in Amazon Web Services (AWS).

Through this vulnerability, the attacker could nab credentials to gain access into all the resources to which the WAF had access. Unfortunately, the WAF was assigned excessive permissions — namely, it (and the attacker) could list all the files in any bucket of data and read the contents of those files. This allowed the attacker to access a sensitive S3 bucket.

The most effective way to mitigate this type of identity abuse is by enforcing the principle of least privilege. [Editor's note: The author's company is one among many that use a least-privilege access approach to cloud security services.] Ideally, every user or application should be limited to only the exact permissions required.

The first step for implementing least privilege is understanding which permissions a user (whether human or machine) or application has been granted. The next step is to map all the permissions actually being used. Comparing the two reveals the permission gap, which exposes those that should be maintained and those that should be revoked. This process must be routinely performed on a continuous basis to maintain least privilege over time.

To illustrate how this process works in the cloud, let's use AWS because it is the most popular 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 more than 2,500 permissions (and counting) to achieve fine-grained control over which actions can be performed on a given resource.

Step 1: Examine Attached Policies
The first step is to examine policies attached directly to the user. There are two types of policies:

Step 2: Analyze IAM Groups
The next step is to review each of the IAM groups to which a user belongs. These also have attached policies that indirectly grant a user access to additional resources. Just as with the user itself, groups may be attached to both managed and inline policies.

Step 3: Map IAM Roles
Now, all IAM roles attached to a user need to be mapped. A role is another type of identity that can be created in an organization's AWS account with associated policies that grant specific permissions. It is similar to an IAM user, but instead of being uniquely associated with a person, a role can be assigned to anyone who requires its permissions. Roles are often used to grant access permissions to applications.

Step 4: Survey Resource-Based Policies
Next, the focus of this exercise shifts from user policies to policies attached to resources such as an AWS bucket. These policies may grant a user permission to perform actions on a bucket directly, independent of all other policies (direct and indirect) that exist. It's extremely important to conduct a comprehensive review of all AWS resources and their policies, especially those that contain sensitive data.

Step 5: Analyze Access Control Lists
Once the policy review is complete, analysis should move to the access control lists (ACLs) linked to each resource. These are similar to resource-based policies and allow control over which identities in other accounts may access the resource. Since ACLs cannot be used to control access for identities within the same account, it is possible to skip all resources held in the same account as the user.

Step 6: Review Permission Boundaries
In this step, we need to review the permissions boundary for each user. This is an advanced feature that defines the maximum permissions a user, group, or role may have. In other words, a permission boundary for a user defines the actions they are allowed to perform based on both the attached policies and the permissions boundaries. It is important to note that permissions boundaries do not affect every policy the same way. For example, resource-based policies are not limited by the permissions boundary and an explicit deny in any of these policies overrides the allow.

Step 7: Check Service Control Policies
Finally, it's necessary to review service control policies (SCPs). These are conceptually similar to permission boundaries defined on all the identities (that is, users, groups, and roles) within an AWS account. An SCP is defined at the AWS organization level, and may be applied to specific accounts.

Enforcing Least-Privilege Access
As we've seen, securing identities and data in the cloud is challenging, and becomes increasingly more complex as organizations expand their cloud footprint. In many cases, users and applications tend to accumulate permissions that far exceed their technical and business requirements, which results in a permissions gap.

Often, the effort required to determine the precise permissions necessary for each user or application in a complex environment like AWS is prohibitively expensive and doesn't scale. Even simple tasks like understanding the permissions granted to a single human user can be extremely difficult.

In an attempt to automate some of these processes, a few years ago AWS released a tool called Policy Simulator that enables administrators to select any AWS entity (that is, an IAM user, group, or role) and service type (such as a Relational Database Service or an S3 bucket) and automatically assess the user permissions for a specific service.

Although Policy Simulator is a great tool, it's far from mature. For example, Policy Simulator does not review all the roles a user may assume and their policies (Step 3). It also does not consider ACLs (Step 5) or permission boundaries (Step 6). In most instances, organizations are forced to perform manual policy management or write proprietary scripts.

As we've seen, managing identities and access in cloud environments to enforce least privilege policies is complicated, labor intensive, and expensive. Since this discipline is still in its infancy, it lacks reliable native tools from cloud platform providers. As is usually the case, third-party solutions are emerging to fill the void.

Related Content:

A listing of free products and services compiled for Dark Reading by Omdia analysts to help meet the challenges of COVID-19.