DIY Access Security for Amazon Web Services

By now, most security professionals are familiar with the cloud shared responsibility model. At its core, it means cloud service providers (CSPs) are responsible for the security of the cloud and customers are responsible for securing the data they put in the cloud. Let’s take Amazon Web Services (AWS) as an example.

Amazon Elastic Compute Cloud (Amazon EC2) is categorized as Infrastructure as a Service (IaaS) and, as such, requires the customer to perform all of the necessary security configuration and management tasks. This includes managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.

Consider the last requirement in the statement above, “applying the appropriate permissions.” This is also sometimes referred to as enforcing least-privilege access. On the surface, enforcing appropriate permissions or least-privilege in AWS should be straight forward.

It involves monitoring the permissions each identity (user, machine or application) is actually using, comparing this activity with the assigned permissions, and using profiling data to right-size roles and permissions. By continually re-examining the environment and removing excessive permissions, least privilege can be achieved and maintained over time.

In practice, this is easier said than done. That’s because managing roles is not enough to achieve least privilege. Even a simple task like understanding the permissions granted to a single human user can be extremely complex.

An AWS policy allowing the principal to list an S3 bucket

To understand how to evaluate and untangle user and application permissions in AWS, let’s look at some common scenarios and concepts including role rightsizing, role splitting, and role chaining. And how to use native AWS tools — Policy Simulator, Access Advisor, and CloudTrail — to achieve least-privilege.

Policy Simulator

Introduced a few years ago, AWS Policy Simulator helps automate permissions management. This free tool allows administrators to select any AWS entity (an IAM user, group, or role) and service type (i.e. a Relational Database Service, or an S3 bucket) and automatically assess the permissions a user has to the specific service selected.

While Policy Simulator is very useful, it is far from mature. For example, it does not review all the roles a user may assume and their policies, does not consider ACLs, or permission boundaries.

Moreover, Policy Simulator does not allow a query to be reversed in order to assess which users may (directly or indirectly) access a specific resource (e.g. S3 bucket). This action must be performed manually, or by writing proprietary scripts.

Identifying allowed and denied permissions in the IAM Policy Simulator

Access Advisor and Rightsizing

Next, let’s consider role rightsizing, which requires making sure that a given role only has the permissions it requires to fulfill its business function. AWS provides a native tool called Access Advisor for investigating the list of services accessed by a given role and verifying how it is being used.

Consider a simple example, where an application is using a role that has permission to access Amazon RDS and S3 services but is only using a single instance of MySQL. Access Advisor will show that Amazon RDS was the only service accessed. This would enable us to remove the excessive S3 permissions. However, it does not list which resources within the RDS service (i.e. MySQL) were accessed. This would prevent us from removing the existing and unnecessary permissions to all the databases in the environment. Access Advisor provides some basic capabilities, but clearly not enough.

CloudTrail to the Rescue

Continuing with this example, the next step would be to limit the permissions of this role so it only provides access to MySQL resources, and not all resources that belong to the RDS service type. Taking this approach one step further, we likely should limit the role’s access to a specific database instance. This requires the ability to understand the activities performed by the role, which can be accomplished using a third AWS tool, called AWS CloudTrail.

Snapshot from CloudTrail log entry

Role Splitting

In a different yet very common scenario, two different applications share the same role. Suppose, as before, that this role has access permissions to Amazon RDS and S3 services. If one application is using a MySQL database, and the other is accessing an S3 bucket, Access Advisor will show that all the services defined within the role are actually being used.

The challenge now is to determine whether each of these two applications requires access to all of the resources defined within the role and what type of access is “actually” needed in order to adjust the permissions as required. Since this level of granularity is not available in Access Advisor, it’s necessary to search through the CloudTrail logs, and correlate these with logs obtained from the compute infrastructure running the applications (e.g. EC2, Lambda, ECS).

In our example, since each application is using a different set of services to achieve least-privilege we would need to assign each application a different role, an action called role-splitting. Only after we split the original role, and assign each application a role of its own, can we perform rightsizing.

Splitting one broad role into two, fine-grained roles

Role Chaining

In our last scenario, consider an application that assumes a role (we will call it Role1) that does not have any sensitive permissions. However, this role has the permission to assume a different, more privileged role (which we will call, for consistency, Role2), which has permission to access a variety of services like Amazon ElastiCache, RDS, DynamoDB, and S3. We refer to such scenarios as “role chains.”

To complicate matters, “role chains” can consist of more than two roles. In these types of situations, it’s impossible to understand and rightsize access permissions without the ability to map the role chains within, as well as between AWS accounts. Attempting to do so with native AWS IAM tools is virtually impossible.

Role Chaining where Role1 has permissions to assume a privileged Role2

As we’ve seen, managing identities and access in AWS using native, or do-it-yourself tools is extremely complicated, time-consuming and error-prone. Yet, the data breach risks associated with misconfigurations and excessive access privileges are well documented.

As organizations expand their cloud footprint, users and applications tend to accumulate permissions that far exceed technical and business requirements. Monitoring and remediating this permissions “gap” requires automated, purpose-built solutions.

Amazon Web Services is a sponsor of The New Stack.

Feature image via Pixabay.