Example scenarios for using last accessed information

You can use last accessed information to make decisions about the permissions that you grant to your IAM entities or AWS Organizations entities. For more information, see Refine permissions in AWS using last accessed information.

Note

Before you view the access information for an entity or policy in IAM or AWS Organizations, make sure that you understand the reporting period, reported entities, and the evaluated policy types for your data. For more details, see Things to know about last accessed information.

It's up to you as an administrator to balance the accessibility and least privilege that's appropriate for your company.

Using information to reduce permissions for an IAM group

You can use last accessed information to reduce IAM group permissions to include only those services that your users need. This method is an important step in granting least privilege at a service level.

For example, Paulo Santos is the administrator in charge of defining AWS user permissions for Example Corp. This company just started using AWS, and the software development team has not yet defined what AWS services they will use. Paulo wants to give the team permission to access only the services they need, but since that is not yet defined, he temporarily gives them power-user permissions. Then he uses last accessed information to reduce the group's permissions.

Paulo creates a managed policy named ExampleDevelopment using the following JSON text. He then attaches it to a group named Development and adds all of the developers to the group.

Note

Paulo's power users might need iam:CreateServiceLinkedRole permissions to use some services and features. He understands that adding this permission allows the users to create any service-linked role. He accepts this risk for his power users.

{

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToAllServicesExceptPeopleManagement",
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Paulo decides to wait for 90 days before he views the last accessed information for the Development group using the AWS Management Console. He views the list of services that the group members accessed. He learns that the users accessed five services within the last week: AWS CloudTrail, Amazon CloudWatch Logs, Amazon EC2, AWS KMS, and Amazon S3. They accessed a few other services when they were first evaluating AWS, but not since then.

Paulo decides to reduce the policy permissions to include only those five services and the required IAM and Organizations actions. He edits ExampleDevelopment policy using the following JSON text.

Note

Paulo's power users might need iam:CreateServiceLinkedRole permissions to use some services and features. He understands that adding this permission allows the users to create any service-linked role. He accepts this risk for his power users.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToListedServices",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "kms:*",
                "cloudtrail:*",
                "logs:*",
                "ec2:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

To further reduce permissions, Paulo can view the account's events in AWS CloudTrail Event history. There he can view detailed event information that he can use to reduce the policy's permissions to include only the actions and resources that the developers need. For more information, see Viewing CloudTrail Events in the CloudTrail Console in the AWS CloudTrail User Guide.

Using information to reduce permissions for an IAM user

You can use last accessed information to reduce the permissions for an individual IAM user.

For example, Martha Rivera is an IT administrator responsible for ensuring that people in her company do not have excess AWS permissions. As part of a periodic security check, she reviews the permissions of all IAM users. One of these users is an application developer named Nikhil Jayashankar, who previously filled the role of a security engineer. Because of the change in job requirements, Nikhil is a member of both the app-dev group and the security-team group. The app-dev group for his new job grants permissions to multiple services including Amazon EC2, Amazon EBS, Auto Scaling, Amazon S3, Route 53, and Elastic Transcoder. The security-team group for his old job grants permissions to IAM and CloudTrail.

As an administrator, Martha signs into the IAM console and chooses Users, chooses the name nikhilj, and then chooses the Last Accessed tab.

Martha reviews the Last Accessed column and notices that Nikhil has not recently accessed IAM, CloudTrail, Route 53, Amazon Elastic Transcoder, and a number of other AWS services. Nikhil has accessed Amazon S3. Martha chooses S3 from the list of services and learns that Nikhil has performed some Amazon S3 List actions in the last two weeks. Within her company, Martha confirms that Nikhil has no business need to access IAM and CloudTrail anymore because he is no longer a member of the internal security team.

Martha is now ready to act on the service and action last accessed information. However, unlike the group in the previous example, an IAM user like nikhilj might be subject to multiple policies and be a member of multiple groups. Martha must proceed with caution to avoid inadvertently disrupting access for nikhilj or other group members. In addition to learning what access Nikhil should have, she must determine how he is receiving these permissions.

Martha chooses the Permissions tab, where she views which policies are attached directly to nikhilj and those attached from a group. She expands each policy and views the policy summary to learn which policy allows access to the services that Nikhil is not using:

• IAM – The IAMFullAccess AWS managed policy is attached directly to nikhilj and attached to the security-team group.

• CloudTrail – The AWSCloudTrailReadOnlyAccess AWS managed policy is attached to the security-team group.

• Route 53 – The App-Dev-Route53 customer managed policy is attached to the app-dev group.

• Elastic Transcoder – The App-Dev-ElasticTranscoder customer managed policy is attached to the app-dev group.

Martha decides to remove the IAMFullAccess AWS managed policy that is attached directly to nikhilj. She also removes Nikhil's membership to the security-team group. These two actions remove the unnecessary access to IAM and CloudTrail.

Nikhil's permissions to access to Route 53 and Elastic Transcoder are granted by the app-dev group. Although Nikhil isn't using those services, other members of the group might be. Martha reviews the last accessed information for the app-dev group and learns that several members recently accessed Route 53 and Amazon S3. But no group members have accessed Elastic Transcoder in the last year. She removes the App-Dev-ElasticTranscoder customer managed policy from the group.

Martha then reviews the last accessed information for the App-Dev-ElasticTranscoder customer managed policy. She learns that the policy is not attached to any other IAM identities. She investigates within her company to make sure that the policy will not be needed in the future, and then she deletes it.

Using information before deleting IAM resources

You can use last accessed information before you delete an IAM resource to make sure that a certain amount of time has passed since someone last used the resource. This applies to users, groups, roles, and policies. To learn more about these actions, see the following topics:

• Users – Deleting a user

• Groups – Deleting a group

• Roles – Deleting a role

• Policies – Deleting a managed policy (this also detaches the policy from identities)

Using information before editing IAM policies

You can review last accessed information for an IAM identity (user, group, or role), or for an IAM policy before editing a policy that affects that resource. This is important because you don't want to remove access for someone that is using it.

For example, Arnav Desai is a developer and AWS administrator for Example Corp. When his team started using AWS, they gave all developers power-user access that allowed them full access to all services except IAM and Organizations. As a first step towards granting least privilege, Arnav wants to use the AWS CLI to review the managed policies in his account.

To do this, Arnav first lists the customer managed permissions policies in his account that are attached to an identity, using the following command:

aws iam list-policies --scope Local --only-attached --policy-usage-filter PermissionsPolicy

From the response, he captures the ARN for each policy. Arnav then generates a report for last accessed information for each policy using the following command.

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1

From that response, he captures the ID of the generated report from the JobId field. Arnav then polls the following command until the JobStatus field returns a value of COMPLETED or FAILED. If the job failed, he captures the error.

aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9

When the job has a status of COMPLETED, Arnav parses the contents of the JSON-formatted ServicesLastAccessed array.

 "ServicesLastAccessed": [
        {
            "TotalAuthenticatedEntities": 1,
            "LastAuthenticated": 2018-11-01T21:24:33.222Z,
            "ServiceNamespace": "dynamodb",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/IAMExampleUser",
            "ServiceName": "Amazon DynamoDB"
        },

        {
            "TotalAuthenticatedEntities": 0,
            "ServiceNamespace": "ec2",
            "ServiceName": "Amazon EC2"
        },

        {
            "TotalAuthenticatedEntities": 3,
            "LastAuthenticated": 2018-08-25T15:29:51.156Z,
            "ServiceNamespace": "s3",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:role/IAMExampleRole",
            "ServiceName": "Amazon S3"
        }
    ]

From this information, Arnav learns that the ExamplePolicy1 policy allows access to three services, Amazon DynamoDB, Amazon S3, and Amazon EC2. The IAM user named IAMExampleUser last attempted to access DynamoDB on November 1, and someone used the IAMExampleRole role to attempt to access Amazon S3 on August 25. There are also two more entities that attempted to access Amazon S3 in the last year. However, nobody has attempted to access Amazon EC2 in the last year.

This means that Arnav can safely remove the Amazon EC2 actions from the policy. Arnav wants to review the current JSON document for the policy. First, he must determine the version number of the policy using the following command.

aws iam list-policy-versions --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1

From the response, Arnav collects the current default version number from the Versions array. He then uses that version number (v2) to request the JSON policy document using the following command.

aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --version-id v2

Arnav stores the JSON policy document returned in the Document field of the PolicyVersion array. Within the policy document, Arnav searches for actions with in the ec2 namespace. If there are no actions from other namespaces remaining in the policy, then he detaches the policy from the affected identities (users, groups, and roles). He then deletes the policy. In this case, the policy does include the Amazon DynamoDB and Amazon S3 services. So Arnav removes the Amazon EC2 actions from the document and saves his changes. He then uses the following command to update the policy using the new version of the document and to set that version as the default policy version.

aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --policy-document file://UpdatedPolicy.json --set-as-default

The ExamplePolicy1 policy is now updated to remove access to the unnecessary Amazon EC2 service.

Other IAM scenarios

Information about when an IAM resource (user, group, role, or policy) last attempted to access a service can help you when you complete any of the following tasks:

• Policies – Editing an existing customer-managed or inline policy to remove permissions

• Policies – Converting an inline policy to a managed policy and then deleting it

• Policies – Adding an explicit deny to an existing policy

• Policies – Detaching a managed policy from an identity (user, group, or role)

• Entities – Set a permissions boundary to control the maximum permissions that an entity (user or role) can have

• Groups – Removing users from a group

Using information to refine permissions for an organizational unit

You can use last accessed information to refine the permissions for an organizational unit (OU) in AWS Organizations.

For example, John Stiles is an AWS Organizations administrator. He is responsible for ensuring that people in company AWS accounts do not have excess permissions. As part of a periodic security audit, he reviews the permissions of his organization. His Development OU contains accounts that are often used to test new AWS services. John decides to periodically review the report for services that have not been accessed in more than 180 days. He then removes permissions for the OU members to access those services.

John signs into the IAM console using his management account credentials. In the IAM console, he locates the Organizations data for the Development OU. He reviews the Service access report table and sees two AWS services that have not been accessed in more than his preferred period of 180 days. He remembers adding permissions for the development teams to access Amazon Lex and AWS Database Migration Service. John contacts the development teams and confirms that they no longer have a business need to test these services.

John is now ready to act on the last accessed information. He chooses Edit in AWS Organizations and is reminded that the SCP is attached to multiple entities. He chooses Continue. In AWS Organizations, he reviews the targets to learn to which Organizations entities that the SCP is attached. All of entities are within the Development OU.

John decides to deny access to the Amazon Lex and AWS Database Migration Service actions in the NewServiceTest SCP. This action removes the unnecessary access to the services.