In the last blog, we covered a few and important security practices of AWS IAM but unfortunately, we didn’t cover many security options. So, we bring to you another AWS IAM blog. This blog covers the other remaining and also the important AWS IAM security options. So, it’s time to wear your ironman suit and get started with security edition part-2 [ The endgame ]. Here we go!
Before we start, just to let you know, we’ve already covered multiple security options and talked about why there is a need for security in AWS IAM in the last blog – AWS IAM: Security edition [part-1] related to AWS IAM security.
We’ve also covered multiple IAM blogs that you can read and take help from to enhance your knowledge related to IAM. To explore more, visit my blog profile for more IAM blogs.
In this blog, we’ll cover other AWS IAM security options. Few of them are provided as an option by AWS IAM. Some of them are not a part of AWS IAM but are marked as the best security practices.
Delegate by using roles instead by sharing credentials
When we talk about authentications, there is a term in AWS IAM called access keys. Access key is a type of credential which is used as authentication to get resources or responses from AWS. Access keys are very important & mandatory for AWS SDK & CLI communication.
There are lots of ways through which we can provide authentication method or credentials like using permanent access keys & IAM roles. Both methods use the same phenomenon of using access keys [ ACCESS KEY & SECRET KEY ] but the difference is AWS IAM roles provide temporary access keys or credentials for a short period of time using STS, as we discussed in the last AWS IAM: best practices [ part 2 ] blog. Generally, the AWS role has its scope and is considered for a small area like AWS services, other AWS account users or federated users.
Instead of sharing permanent user keys, we can attach roles to resources [ AWS resource/ other AWS account user/ federated user].
Remove unnecessary users and credentials
When we talk about resources, we always try to make everything clean to make sure we don’t pay for extra resources that we are not using. If we don’t clean things that we are not using, it can lead to disorganisation of things and confusion.
It’s really important to track IAM users last activity & sign-on because tracking unnecessary users or too many users who are not using their AWS accounts can lead to big mess. It’s really important to track all these kind of users & more important to remove them from AWS account.
When we talk about large organisations, where there can be a huge number of AWS IAM users and when we talk about numbers in AWS IAM, we need to remember quota or resource limit. If we do not take care of unnecessary resources, the IAM specialist or admin would have to face resource quota exceed issue and has to give extra time to fix this issue. It’s better to take care of these things after a certain interval of time. Also, it’s a good practice to monitor such kind of activity.
Credentials report is one of the options provided by AWS IAM through which we can get the last activity & sign-on information of all the users. It provides a CSV format file through which can get and use that list to create a script and remove left-over users.
Users can also get information from the AWS IAM dashboard but through this we can only visualise and not be able to download report for further automation. To know more about credentials report, visit AWS official documentation.
Configure a strong password policy
For AWS SDK & CLI communication or using AWS IAM roles, there is no requirement of password authentication but there are some scenarios where password authentication is required to access AWS resource. Console access is one of the things in which password authentication is required but when we talk about password-based authentication, there is always a requirement of security.
In the last blog, we had talked about MFA and source IP based authentication, which provides a high-level security but when we talk about console access or users who only need console access, password authentication comes first. So, by applying password policy, we are adding an extra layer of security through which user has to provide complicated or non-dictionary password due to which non-authorised user won’t be able to guess or break the first layer of AWS console authentication. This increases and enhances security.
To apply this functionality provided by AWS IAM, under IAM section -> On the left side -> click Account settings
Under Account settings -> click Change password policy, this option will provide multiple security options related to password policy.
This password policy option is global in nature, which means if AWS IAM admin will apply this option, it will automatically be applied for all users and it would be mandatory for all the IAM users to follow same options configured for password policy.
Here ,we discussed why we should delegate roles instead of AWS permanent credentials and also talked about how role uses AWS STS services to provide temporary credentials which we had also discussed in the last best practice blog.
We also discussed why there is a need for regular logging and monitoring of resources to keep everything clean and to pay for & manage only those things that we are using. Password policy is another option that is provided by AWS IAM and we discussed, why there is a need for this feature in AWS IAM and how can we use this feature to manage and secure our resources.
And yes, we finally defeat Thanos 🙂
If you are new here, you can checkout our previous blog of the AWS IAM series which cover AWS IAM introduction, best practices & options:
- AWS IAM: The challenge
- AWS IAM: Best practices [Part 1]
- AWS IAM: Best practices [ part 2 ]
- AWS IAM: Security edition [Part-1]
Let us know in the comment section if you want more AWS IAM practices series or if you have comments or suggestions, not only related to AWS IAM security but also related to AWS IAM.
Blog Pundit: Kapendra Singh
Opstree is an End to End DevOps solution provider