Guilherme Ferreira
The AWS Identity and Access Management service is where you control users, groups, roles, and their security credentials, allowing or denying any request to other integrated AWS services with IAM.
Even if it seems quite obvious, you should always pay attention to what permissions and to whom you are giving access over your AWS account.
To make things simple, I have listed below a group of best practices that you must follow to keep your account secure and far from the leak of information and credentials.
Least Privileges Principle
This statement says that you always should give only the necessary permissions that are needed to proceed the demanded tasks.
For instance, if the task is related with only checking the number and instance types deployed, so why would you grant to this user admin access or even possibly let him deploy any extra resources?
Don’t use your root account!
The root account is the account that you have created while signing to use AWS.
This account has by default permission to do anything, so you can imagine the nightmare if, for whatever reason, someone not known get access to it.
The recommendation here is to create a user with admin permissions and, when necessary, make use of this account instead of the root one.
A good tip is to use the PowerUserAccess policy. This policy gives an admin-like set of permissions but, with the restriction of managing users and groups, as shown by the example below:
No access keys for the root account
Seems quite obvious to avoid it by the explanation above but in some cases, unfortunately, this goes unnoticed!
If that is your case, try to verify where those access keys are being used in your environment, then move all that is needed to IAM Roles and immediately remove it!
Activate MFA (Multi-factor authentication)
The multi-factor principle is based in two concepts explained by what you know (your user and password) and what you have (physical or virtual MFA device). These two items are what is required for you to login in your account.
Using MFA creates another layer of protection and even if your password gets exposed, the new holder will still have to get the MFA to be able to log in.
MFA on AWS works either for user authentication (available for the root account too!) or while doing service API request that needs protection because of sensitive data or security compliance.
Never store users credentials in EC2 Instances
This one is EXTREMELY IMPORTANT!
You may be tempted to store users access and secret keys in your EC2 instances to provide communication between your application and other AWS Services but, if this is the case, DON’T EVER DO THAT!
Developers constantly publish their code in platforms like GitHub, BitBucket, etc. and in that case, your credentials will be easily leaked!
Another issue can rely when you delete or rotate the user keys and, because this action will take effect almost immediately, applications depending on this particular set of keys will stop to work without warnings!
Assuming IAM roles is the key in here!
Rotate users credentials
Rotating keys is part of security best practices and when you make use of IAM Roles, this rotation is already done automatically by the use of AWS STS (Security Token Service). Usually, this rotation (using IAM Roles) happens not later than five minutes before it expires.
If you need to rotate the user’s credentials manually, you can do either by the AWS Console or API calls.
In case of compromised resources in your environment, you must do it as soon as possible and please, keep always in mind the use of IAM Rules as I mentioned above!
Create a password rotation policy
A password rotation policy is like a requirement that must be respected when a user is registering his password.
Following best practices to keep your users with a strong password, you can create a policy that asks for some numbers, capital letters and special characters to be part of it.
An expiration period can also be enabled to force them to renew the password.
Manage users permissions with groups
This is more related to convenience!
Imagine that in your company you have a department with 20 developers and basically everyone needs the same set of permissions. Instead of attaching policy one by one, for each user, why not put them all together in a group and, by the group, you associate the needed permissions?
… and more
I think that some other points related to the IAM Service are worth to mention, see below:
- By default, when a new IAM User is created it comes with the so-called implicit deny.
- It means that NO permission is associated with the user and you need to explicitly grant it!
- Always, an explicit DENY will override an explicit ALLOW!
- In case that you need to revoke permissions fast for an IAM User or Group, you can easily attach a policy denying everything that is needed!
- IAM Service is FREE and GLOBALLY available.
- You don’t pay for IAM usage, only for the resources deployed under users control and, you cannot define permissions especially for different AWS Regions, though, you can make use of IAM Conditions for regulatory standards security compliance.
- For convenience, you can set up a user-friendly URL to access your AWS Console (instead of the account ID).
- It can be done by editing the IAM users sign-in link in the main page of the IAM Service.
As always, if you hungry for knowledge and want a more deep-dive understanding, you can see the official AWS article with IAM Best Practices.
