Today, we’re talking about inactive users in AWS IAM.
AWS IAMÂ (for Identity and Access Management) is a web service provided by AWS that enables your organization to control access to AWS resources securely. You can create and manage users and groups through IAM and use permissions to allow and deny their access to AWS resources. This helps to ensure that only authorized users have access to sensitive information and that access is controlled and logged for compliance and security purposes.
Sometimes, users can become inactive for several reasons that may or may not be registered. Below we’re going to see about the risks induced and how to avoid them through Mindflow and learn how to orchestrate 4 tools.
The risks of having inactive users in AWS IAM
Several issues can arise when having inactive users in AWS IAM:
- Security risk: Inactive users may still have access to sensitive data and resources, which could potentially be compromised if their credentials are exposed. This could result in data breaches or other security incidents.
- Compliance risk: Having inactive users may create compliance issues, such as if the inactive user is no longer authorized to access certain data or resources but still has permission.
- Cost: Inactive users may still be consuming resources and incurring costs, such as storage or compute resources.
- Confusion: Inactive users can make it difficult to understand who has access to resources, which can make it harder to troubleshoot issues or investigate security incidents.
- Governance: Many inactive users can make it difficult to keep track of who has access to what resources and make it hard to revoke or update permissions.
- Risk of Account takeover: if an inactive user’s credentials are compromised, it can be used by an attacker to access the resources of the inactive user.
These risks highlight why it’s essential to regularly review and remove inactive users from your AWS IAM to minimize security and compliance risks, lower costs, and improve the governance of your AWS environment.
What can be done to reduce these risks?
There are a few ways to disable inactive users in AWS IAM. You can either delete the user, deactivate their access keys, revoke their permissions, or mark them inactive.
In this use case, we’ll go with deleting the inactive user because of the risks they induce on the organization. An organization typically runs dedicated sessions to review the users’ lists and assess whether some should be deleted. Although this is an excellent start, these access control review sessions are usually performed annually, and a lot can happen between them.
You typically need multiple tools to review and, if required, other tools and information to gather should you decide to delete inactive users. In this case, as we said above, you need to go to the AWS IAM console, then ask the relevant manager or admin on Slack, wait for their answer, create a ticket in Jira, gather information on AWS CloudTrail about the last actions, then decide to delete inactive users in AWS IAM.
This is why automating parts of this process to be able to reduce the time spent performing it is interesting. Through asynchronous execution, such reviews can be achieved more regularly to reduce the risks associated with residual inactive users in AWS IAM.
The following Flow can be executed on a predetermined regular basis to:
- automatically get all users listed in your organization on AWS IAM
- extract the information of every user
- to compare the last login time, and
- if older than 3 weeks, ask the admin on Slack
- following their answer to create a ticket in Jira gathering the relevant information
- populate the ticket with additional information gathering through CloudTrail
- to finally perform the user’s deletion in AWS IAM.
