Quick Start to AWS: IAM Best Practices

AWS Identity and Access Management

Last Updated: 28th March 2021

This is the first of my series for “Quick Start to AWS”, which serves to help individuals and perhaps even organizations quickly get started easily on AWS Cloud. It is meant to be beginner-friendly and easy to understand, so as to not overload my audience with the vast capabilities of AWS. This piece focuses on a very crucial element of all workloads and use cases of AWS, AWS IAM.

AWS IAM stands for Amazon Web Services Identity and Access Management. AWS IAM is a web service that helps you securely control access to AWS resources. IAM is used to control who is authenticated and authorized to use your AWS resources.

Whenever you create an AWS account, you begin with a single user, known as the root account. This root account has complete access to all AWS services and resources and is accessed by logging into AWS using your root email and password that was used to create the account.

With IAM and your root account, you can create and manage IAM users and groups, as well as assign permissions to allow or deny access and actions to specific AWS resources. IAM is available at no extra cost and you are only charged for resources deployed by your IAM users as per normal AWS service billing.

This piece serves to help you get started quickly with some of IAM’s best practices in order to keep your AWS account and resources secure. Take note that this only includes some of the more common best practices and is not exhaustive, always review and look for ways to improve the security of your AWS environment.

The AWS root account is very convenient to use for whatever tasks you may be doing as it has access to everything. However, this unlimited control also makes it the biggest risk should the root account be compromised and used in the hands of a malicious user.

The best practice after creating an AWS account is to create an IAM user for yourself and give him Administrator permissions. Afterwards, delete all AWS root account user access keys that are unneeded and never share the password with anyone. Oh, and do I have to mention that the password should be a strong one too?

For extra security, IAM offers the option of requiring your IAM users to use Multi-Factor Authentication (MFA) for all sign-in attempts. With MFA enabled, an authentication challenge is presented to the IAM user when he tries to sign in. This helps protect IAM user accounts from being accessed even if the password and username were to be compromised.

To enable MFA, you would have to utilize a virtual or hardware MFA device that will generate a 6-digit code to be entered along with the IAM username and password to complete any login attempts successfully. There are multiple options for the MFA device, but personally, I prefer using Google Authenticator as it is convenient to just have on my phone which I always bring around, instead of bringing another token or small MFA device.

AWS recommends that MFA be required for all IAM users in your account, especially for privileged IAM users who are allowed access to sensitive resources, API operations or destructive actions such as terminating EC2 instances.

For certain workloads, you may have applications that run on EC2 instances that may require access to other AWS services such as Amazon S3 or DynamoDB. To provide access to these roles, you might choose to store credentials on the EC2 instance to give it permission to access the other services.

Instead of that, you could instead use IAM roles. Roles are entities that have their own set of permissions and can be assumed by a user or resource in order to accomplish a need or task. Roles do not provide permanent permissions and instead dynamically provides temporary credentials to resources or users who need them. In this case, assign an IAM role to the EC2 instance would provide it with temporary credentials to access other AWS services that it needs. These credentials are automatically rotated frequently.

Using IAM Roles to provide applications with the required credentials to access other AWS services is a much safer way to accomplish the same goal as compared to storing credentials in plaintext on the EC2 instance itself. Furthermore, assuming you have more than 1 EC2 instance, you don’t need to keep storing and updating credentials individually on each instance, but instead, just apply the same role to all instances that need it.

When creating IAM policies to assign permissions to IAM users and groups, always follow the standard security principle of granting the least privilege, which means to only grant the permissions required to complete a specific task.

Before writing a policy, determine and list out what are the specific actions that a user needs to be able to do, and craft policies that only grant those specific actions and nothing more. This helps make your environment more secure as users are unable to carry out actions that were not intended for them.

One example is when assigning an IT manager access to list all EC2 instances. Instead of giving him access to all actions of EC2, such as starting instances, you can instead only give him permission to only list EC2 instances. This will prevent any unexpected actions such as terminating crucial machines and starting unused instances which would result in costly consequences.

When you create multiple IAM users for all your employees or team members, it is crucial that all of them have strong passwords set to ensure that their accounts are not as easily compromised.

Some examples of weak passwords are “123”, “ABC” and “password”. These may seem silly but the fact that users usually use weak passwords still remains. In fact, according to NordPass, the most common password used in 2020 was “123456”, which was used by 2.5 million users. This password is able to be cracked by most modern-day computers in less than a second.

To ensure that all users create strong passwords, IAM allows you to create custom password policies that require users to only create passwords that fit your requirements. Some configurable aspects include minimum length, the requirement of nonalphabetic characters and password expirations.

If you need some inspiration or ideas on what is a strong password, you can follow the NIST Password Guidelines and Best Practices for 2020 that is published on Auth0. Some simple guidelines include:

  • Using of uppercase, lowercase, numbers and nonalphanumeric characters
  • Making sure your passwords are at least 12 characters long
  • Using special and non-keyboard symbols or characters
  • Do not reuse passwords
  • Changing your passwords every 3 months

Some example of strong passwords include “X5j13$#eCM1cG@Kdc”, Il0vEmU$keETerS!” and more.

Conclusion

That about sums up five very quick best practices that you can apply to your AWS account using AWS IAM. I hope that this piece has helped you better secure your AWS environment and enabled you to quickly and easily get started on AWS without being intimidated by the vast functions and features that AWS offers.

Kindly take note that this list is not exhaustive and that there are many best practices that are applicable to IAM in order to better secure your environment. These are just 5 of the most simple and common ones that I feel will help you get started quicker. If you need more best practices, you can check out the AWS Documentation.

Cybersecurity student interested in all things technology and self-improvement. I love learning new things and sharing them with the world.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store