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

As a security best practice, AWS recommends writing AWS Identity and Access Management (IAM) policies that adhere to the principle of least privilege, which means granting only the permissions required to perform a specific task. However, verifying which permissions an application or user actually needs can be a challenge. To help you determine which permissions are needed, the IAM console now displays service last accessed data that shows the hour when an IAM entity (a user, group, or role) last accessed an AWS service. Knowing if and when an IAM entity last exercised a permission can help you remove unnecessary rights and tighten your IAM policies with less effort.

In this blog post, I will first cover the basics of service last accessed data. Next, I will walk through a sample use case to demonstrate how you can use this data to remove unnecessary permissions from an IAM policy.

The Access Advisor tab

When you view a user, group, role, or managed policy in the IAM console, there’s now a new tab called Access Advisor. This tab includes a table that shows service last accessed data. The table contains:

• The list of service permissions granted by the policy, if you’re looking at a managed policy.
• The list of service permissions granted to the IAM entity, if you’re looking at a user, group, or role.
• The date and time when each service was last accessed.

The following screenshot shows an example of viewing service last accessed data on the Access Advisor tab for a customer managed policy.

The meaning of the Last Accessed column depends on whether you’re looking at a managed policy, user, group, or role.

• If you’re looking at a managed policy, the Last Accessed column shows the last time a user, group, or role that the policy is attached to authenticated against a given service.
• If you’re looking at a user or role, the Last Accessed column shows the last time that particular user or role authenticated against a given service.
• If you’re looking at a group, the Last Accessed column shows the last time that a user in that group authenticated against a given service.

Note that “Last Accessed” refers to the time of authentication, which is the last time the service was called using a request signed by using the access keys of the IAM user or role. This is distinct from authorization (see a quick summary of the difference). For example, if an IAM user has Amazon S3 read-only permissions and the user’s most recent action was an attempt to delete an S3 bucket, the delete operation will be denied, but the time stamp of the delete attempt will be displayed in the service last accessed table. For more details, see the service last accessed data documentation.

In addition, the list of services in the Access Advisor tab reflects the current state of your permissions, not their historical states. For example, if the current version of your policy allows only access to S3, but previously it allowed access to all AWS services, the service last accessed table will only show an entry for S3. If you’re trying to determine the history of access control changes in your account or you want to audit historical access, see your AWS CloudTrail logs.

Now that I’ve described service last accessed data, I will show how it can be used in a typical use case.

Sample use case: Scoping down application permissions

Alice is a DevOps administrator responsible for managing her team’s AWS infrastructure. Her team has created an app that runs on Amazon EC2 and calls other AWS services. Therefore, Alice needs to provision EC2 instances and manage their configuration. However, she is new to IAM and when she goes to create the IAM role, she’s not sure what to put in the role’s access policy. Alice is aware of security concerns, but her immediate priority is just to make the application work, so she simply attaches the PowerUserAccess AWS managed policy, which is shown following this paragraph. This policy grants full read/write access to all AWS services and resources in the account except IAM (and is definitely not recommended as a long-term solution.)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "iam:*",
      "Resource": "*"
    }
  ]
}

Using service last accessed data, Alice can scope down these application-specific permissions to remove access to services that are never used. After the application has run for a while, she goes to the IAM console and navigates to the Policies pane. She finds the PowerUserAccess policy associated with her IAM role (which was attached to her EC2 instance), selects it, and then clicks the Access Advisor tab, as shown in the following screenshot.

Alice reviews the service last accessed times and sees that the application is only using Amazon DynamoDB, S3, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), and AWS CloudWatch. Alice can revise the role’s access policy to revoke all permissions except for these by detaching the PowerUserAccess AWS managed policy and writing a custom policy using the policy editor or policy generator. Removing unnecessary permissions based on service last accessed data will help reduce the security surface area of her application’s permissions, in accordance with the principle of least privilege.

This example demonstrates how you can use service last accessed data in a policy-centric way (in other words, viewing the Access Advisor tab from the perspective of a policy) to tackle a common access control problem. In my next blog post, I will show how you can use service last accessed data in a principal-centric way (viewing the Access Advisor tab from the perspective of a user, group, or role) to help improve your account’s security. I will also cover the differences between these two approaches in more detail.

The IAM team would love to hear your thoughts regarding this new feature. If you have comments about service last accessed data or questions about how to use it, leave a comment below or on the IAM forum.

– Kai