Another Way to Remove Unnecessary Permissions in Your IAM Policies by Using Service Last Accessed Data

In my previous post, I introduced service last accessed data, a new feature of the AWS Identity and Access Management (IAM) console that helps you define policies that adhere better to the principle of least privilege. As part of that post, I walked through a sample use case demonstrating how you can use service last accessed data in a policy-centric way. In today’s blog post, I’ll walk through how to use service last accessed data to scope down an application’s permissions in a principal-centric way.

Note: This post assumes that you’ve already read my previous post. As a result, I’ll skip the overview of what service last accessed data is and where to find it, and jump right into the details.

What is a “principal-centric” approach?

A principal-centric approach begins from the perspective of user and application profiles—in other words, viewing the Access Advisor tab for an IAM user, group, or role. When you make permissions changes based on service last accessed data using this approach, it’s important to consider how other principals may be affected. For example, just because IAM user Bob doesn’t seem to be using the Amazon S3 permissions granted by a shared managed policy doesn’t mean that you should immediately remove S3 permissions from that policy, because user Alice might require S3 access.

Now let’s walk through an example of a principal-centric approach to permissions management.

Sample use case – Realigning permissions for an evolving application

In this example, I’ll show you how an application owner can use service last accessed data to reconfigure her application’s permissions.

Donna is a DevOps administrator responsible for managing her team’s AWS infrastructure. One of her organization’s web applications was recently redesigned to use Amazon DynamoDB for storing records; previously, the application used S3. This web application relies on the IAM role app_foo, which has been recently modified to grant DynamoDB permissions in addition to its previous permissions.

Donna signs in to the IAM console and navigates to the Roles pane. Here, she selects the app_foo role, and then clicks the Access Advisor tab, as shown in the following screenshot.

Donna reviews the service last accessed data and sees that DynamoDB has been accessed recently, but S3 was last accessed months ago. Now Donna needs to determine the appropriate next steps to make sure that she doesn’t adversely impact the access of any other services or users.

Donna then goes to the Permissions tab for the app_foo role to see the source of its permissions. When she initially assigned permissions to this role, she used a mix-and-match model of assigning multiple smaller managed policies instead of a single comprehensive policy. As a result, this role has separate policies (shown in the following screenshot) that grant access to Amazon Elastic Load Balancing, Amazon EC2, Auto Scaling, S3, and DynamoDB, respectively. To revoke the now-unnecessary S3 permissions, Donna realizes that the simplest solution is to detach the managed policy that granted S3 permissions (app_foo_s3), rather than make any policy edits.

As a general rule, it’s good to examine a user, group, or role by looking at the policies that contribute to the permission of that user, group, or role. This way, you can verify whether questionable permissions are unnecessary and thus safe to remove, or merely unused by the specific principal you were analyzing.

Next steps

You can use this approach as a starting point for a number of potential next steps in response to unused services, including (but not limited to):

• Detaching a managed policy.
• Deleting a managed policy.
• Deleting an inline policy and creating a managed policy with fewer permissions.
• Editing an existing policy to remove permissions.
• Adding an explicit deny to an existing policy.
• Creating a separate policy for specific principals.
• Doing nothing and acknowledging that not every principal will exercise all their permissions.

It is up to you as an IAM administrator to choose the permissions management approach that strikes the right balance of accessibility and least privilege, while remaining appropriate for your organization.

We’d love to hear your thoughts regarding how you use service last accessed data, as well as suggestions for future releases. If you have comments about service last accessed data or questions about how to use it, leave a comment below or start a thread on the IAM forum.

– Kai