AWS user management
Introduction
In order to keep your AWS environment secure while allowing your users to properly utilize resources, you must ensure that users are correctly created with proper permissions. Also, you must monitor your environment to ensure that unauthorized access does not occur and accounts are up to date.
AWS Solutions Architect
User Account Creation and Management
AWS IAM allows you to create separate users, groups and roles to access your AWS resources (See AWS Identity and Access Management for more information). These user accounts may be created through the GUI console or through the AWS Command Line Interface or API calls.
You should constantly monitor user access to your AWS account. Using CloudTrail (see below) and other logging methods you will be able to determine which users are active within your environment, what services they are using and what permissions they may need when there are failed requests.
It is important to remove any IAM users and access keys which are not in use. Accounts and access keys may be disabled if the user is temporarily not active but may return. Passwords and access keys should be changed frequently to limit the chance of a compromise.
Password Policy
In order to keep your AWS user accounts secure, you must have a strong password policy. AWS allows you to control the complexity of passwords used by your users. Through the AWS Console, CLI or APIs, you are able to control:
- Minimum Password Length
- Required character types (uppercase, lowercase, numbers, etc)
- If users can change their own password
- If user passwords expire
- If passwords can be reused
- If an IAM user must contact an administrator if their password has expired
Please note that if you require your users to contact and administrator when their password expires you should have at least two users with administrator privileges. If there is only one administrator account and their password expires, they will not be able to reset their password. Also, password expiration does not apply to a user’s access keys. The user will still be able to utilize any CLI or API permissions that the account has access to.
The above password policies only apply to IAM users and not the root AWS account password. This is another reason it is necessary to have a complex password and multi-factor authentication on the root account.
Principle of Least Privilege
Another aspect of maintaining security within any system is the principle of least privilege. This principle states that a user should only have the permissions necessary to perform their tasks, no more. Each user should be granted as few permissions as necessary, and then grant additional access when you find the user needs it. This is much easier than granting wide ranging access and removing it when you discover they do not need it.
While initially creating accounts with proper access is not an insurmountable task, often after a while, organizations will suffer from “permissions creep”. This is where users will be granted additional access, maybe for a temporary project, and that access will not be properly removed from the users. This is why periodically auditing users access levels is important to maintaining a secure environment.
Creating and Managing IAM Roles
Similar to IAM users, IAM roles can be created through the console, CLI or APIs. Unlike users, which are permanent accounts within your environment, a role grants temporary permissions to your resources, and can be assumed by any user or resource which needs the access (and has permission to assume the role). This is commonly used to grant access to users from other AWS accounts into your environment, or to allow a mobile app to access AWS resources without having to embed an access key in the code where it may be compromised.
Just as with users, you should monitor which roles are accessing your resources and ensure they have correct permissions. Roles no longer in use should be removed, and the maximum session time a role is allowed to be assumed should be controlled.
Policy Conditions
In addition to setting policies for which resources a user or role can access, IAM also allows you to set conditions which must be met before a user is allowed access. Some examples of conditions allowed within IAM policies are that the request must come from a specific set of IP addresses, or that a request is only allowed during specific times. For example, you can allow that only users within your on-premise network are allowed to create or terminate EC2 instances. It is advised that you use policy conditions where possible to further reduce unauthorized access to your account or resources.
Working with CloudTrail
In order to monitor users and roles accessing your AWS resources, Amazon provides a service called CloudTrail. CloudTrail logs API and console calls from users creating a log of events which you may search view to determine what activity is occurring on your account. CloudTrail is automatically enabled on your AWS account and will keep a record of the past 90 days. If you wish to keep the logs for a longer period, you may configure CloudTrail to send the logs to a specified S3 bucket.
When you view an event in CloudTrail, you will be able to see which user or role made the request, what IP address the request came from, the time it was made and what was requested. This is very helpful for monitoring for suspicious activity and troubleshooting access issues.
AWS Solutions Architect
Conclusion
AWS provides many tools for ensuring that your users accounts are secure and that your resources are only accessed as you intend. Using IAM in combination with CloudTrail is a good start to ensuring you have an understanding of how your environment is being used.
AWS Solutions Architect
Get prepared for the AWS Certified Solutions Architect — Associate exam. What you'll learn:- Resilient architectures
- Performant architectures
- Secure architectures
- Cost-optimized architectures
- And more
Amazon Web Services
Amazon Web Services
Amazon Web Services
Amazon Web Services