A Complete List of AWS IAM Misconfigurations
Amazon Web Service’s (AWS) Identity and Access Management (IAM) permits you to manipulate and get entry to AWS offerings and sources securely. For example, using IAM, you may create and manipulate AWS customers and groups and use permissions to permit or deny their entry to AWS resources.
IAM is a feature of AWS that is presented at no extra charge. However, having AWS IAM Misconfigurations is a constant headache for organizations. A single mistake can be worth millions. Implementing IAM can help you prevent catastrophic events like data breaches and insider attacks. To secure your infrastructure and implement AWS IAM effectively, let us look at a comprehensive list of IAM Misconfigurations that you should avoid!
Here is all you should know about AWS IAM misconfigurations and how your DevOps team can avoid them.
List of AWS IAM Misconfigurations
Using Root account’s access keys
One of the most common IAM misconfigurations is using the root account’s access key. The root account has full permissions across the entire account. Root accounts should not have access keys. Also, it certainly shouldn’t access any service. Instead, create IAM users with predefined roles. Not using Root’s account access keys in your setup will provide a better security posture. This misconfiguration can cause serious security lapses, and if you have such a misconfiguration, it is imperative to get it rectified as soon as possible.
Root Account Access Keys Rotation
Building on the above misconfiguration where we have access keys to root accounts, The root account should not have access keys. If you have that, then the keys should be rotated periodically to decrease the likelihood of accidental exposures and protect your AWS resources against unauthorized access. It is also a requirement for HIPAA, APRA, MAS, and NIST compliance.
Tieing root accounts to certificates
Tieing root accounts to certificates is a severe misconfiguration that can cause massive security lapses. Therefore, certificates should not be tied to root accounts. Rectifying this misconfiguration can help you achieve PCI, HIPAA, APRA, MAS, and NIST compliances.
Root account certificate rotation
Not rotating certificates that are tied to the root account is another misconfiguration. Certificates tied with root accounts need rotation. It also helps you achieve HIPAA, APRA, MAS, and NIST compliances. Therefore, it is essential to rotate root accounts if they are tied with certificates.
MFA for every root account
MFA (Multifactor Authentication) is strongly recommended to be enabled for every account with no exceptions. MFA is an essential security requirement that you should have to protect your data. Lack of MFA can expose your confidential client information to breaches. Avoiding this simple misconfiguration can help you get one step closer to complying with NIST, AICPA, and ISO27001 compliances.
Password rotation on root accounts
Password rotation should be done every 30 days to be safe from any security breaches. This is more of a “prevention is better than cure” kind of misconfiguration. So, ensure that your root account password is rotated every few days.
Account With Too Many Admins
Having too many admins on your AWS account is a misconfiguration. Your AWS account should have a minimum number of admins. A minimum number of admins will improve the quality of the account. 2-3 are the maximum number of admins allowed.
User account without any usage
The next misconfiguration would be keeping an unused account. Any unused IAM user without console access and API access should be removed as an extra security measure for protecting your AWS resources against unapproved access. Rectifying this misconfiguration
MFA on user accounts
AWS recommends that you configure multi-factor authentication (MFA) to help protect your AWS resources. MFA must be enabled on user accounts. Users with console login should be asked to log in and enable Multi-factor authentication for their accounts.
User account access key rotation
Another misconfiguration you might miss is not rotating user account access keys. The access keys should be rotated periodically. It should be rotated every 30 to 60 days.
Inactivity of access keys in IAM Misconfiguration
The misconfiguration is keeping the inactive access keys. Inactive access keys should be dropped after 30 to 60 days of inactivity.
User console access inactive
Keeping the account access of inactive people is another misconfiguration. Users who are infrequent or do not need access to the console should be cleared off their account access.
User account service inactivity
Checking the inactivity of any user on service is very important. Those privileges should be removed for better security posture. Compliance standards required for this are NIST, PCI, ARPA, MAS. The account should be removed after a minimum of 30 days of inactivity.
User account inline policies
IAM users should not have Inline policies. It is recommended that IAM policies be applied directly to groups and roles but not users. This will help you comply with APRA, MAS, AICPA, NIST, and ISO 27001 compliance standards.
A user account with multiple access keys
Another IAM misconfiguration you should avoid is having multiple access keys for a single user account. Instead, there should be just 1 access key per user account.
Role service Inactivity
Roles that have access to services but have not been used in the past several days should be looked into and cleaned up.
Role inline policies
Another misconfiguration that you should rectify is that roles should not have inline policies attached to them.
Groups without users
Holding on to empty groups is a misconfiguration. Empty groups should be cleaned up and should not linger around. The cleaning of groups should be done in a minimum of 30 days.
Complex Password Policy
A misconfiguration you should know is keeping an easy password can lead to many cyber threats. While this is a basic security tip that everyone should keep in mind, ignoring it can cost you and your organization a lot. Password policy should be complex enough so that users can set passwords that are not easy to guess and crack. Compliance standards required in this are CBP, NIST, AICPA, and ISO 27001.
Conclusion
AWS protection may be challenging to appropriately and effectively take on; however, via defensive towards privilege escalation attacks, protecting an AWS surrounding may be advanced significantly. By taking these simple steps, you can avoid the major mistake most organizations make and improve your AWS security.
How can Cloudanix help with AWS IAM Misconfigurations?
Cloudanix (www.cloudanix.com) provides you with the AWS IAM recipe that does regular audits and notifies you if you have any of the above AWS IAM misconfigurations.