AWS IAM Best Practices Checklist for DevSecOps [Real-World Examples Inside]
AWS Tips & Tricks, Cloud Computing

“ AWS IAM is a cloud security practitioners’ primary control mechanism.”


The power of AWS IAM is tremendous. It can make or break a cloud infra’s security posture. That said, without it, securing resources across several teams, projects, and environments would have been a challenge.


Take for instance, Bob, a DevSecOps Lead of a multinational company, recently found suspicious files in on one of the S3 buckets. After a quick check, the audit revealed overly permissive controls to a stale individual AWS IAM role! A regular audit saved the day!


Writing an IAM policy script when you are managing several teams across projects is no less than an art. Over permissions and under permissions affect several dynamics of a cloud infra. Striking the right balance of permissions to every account, resource, and role is the key to continued AWS security.


In this post we walk you through few real-world examples where trivial IAM bad practices proved costly to a team or an organization. Plus, a list of IAM best practices you can print and pin to a wall for quick reference.


Bad IAM Practice Example #1: Using root credentials for your everyday tasks without MFA  


When Bob was new to AWS, he used root credentials unknowingly for his everyday tasks. One day, he had to share these root account credentials to one of his team members, Dev, who left the company within 6 months. Unexpectedly, Dev’s account was hacked and the hackers had access to AWS root account credentials, thus causing a catastrophe.


Bob made three major mistakes with root credentials:

  1. Was using root credentials for his everyday tasks, without enabling multi factor authentication (MFA).
  2. Did not implement the principle of least privilege to an AWS IAM role and then assign it to Dev.
  3. Did’nt monitor his AWS root account credentials usage within the 30 days time frame.


So, Bob should have kept AWS account (root) access keys locked in, enabled MFA for all roles, and should have monitored the account for all activities coming from outside.


Note: Admin is not same as root in AWS. Root has few privileges that admin users do not have.


Bad IAM Practice Example #2: Not using proper IAM roles for apps running on EC2s


Bob’s team was running an app-tier EC2 instance with an IAM role attached to it where the app would upload data to an S3 bucket. Once, his company’s CISO accidently gave delete privileges to this IAM role. As a result, a cron script that was designed to rename objects with similar names started overwriting old data with new data. Outcome: Blunderous results in their Prod environment.


Bob’s CISO made a major mistake of assigning wrong permission that IAM role. AWS has designed IAM roles so that apps can securely make API requests from EC2s. A user can delegate permissions to make API requests to an app-tier instance using IAM roles. But he/she needs to be super cautious while assigning permissions.


Note: Assigning pertinent permissions to an IAM role is crucial. Enabling AWS automatic key rotation feature to these IAM roles is essential.

Bad IAM Practice Example #3: Ignoring managed policies’ permissions that allow admin access to IAM role


Using managed policies are one of the recommended security practices. However, using them wisely and keeping an eye on all the permissions closely is vital. In one scenario, an AWS user disclosed how a policy name allowed admin access to him despite having limited access to his IAM role. In a post, the user describes this security flaw where he was able to add an inline policy granting admin access to any IAM role due to a managed policy named “AmazonElasticTranscoderFullAccess” attached to it.


There are tons of such scenarios. The list goes on.


To have maximum control over your entire AWS infrastructure security, a regular audit with a handy checklist of IAM best practices is essential.

For your convenience, we have made an exclusive downloadable infographic with a list of important best practices related to IAM. *Just right-click on the image and download it for future reference.* 

Is MFA turned on for root account as well as all roles? If not, turn it on. Does your root account have access keys? If yes, delete them. Is your root account user using X.509 certificates to validate API requests? If yes, remove them. Is hardware MFA enabled in root account? If not, enable it. Have you set root user email address to a group email? If not, do it. Are there any access keys left out during creation of IAM user initial setup? Are your AWS IAM access keys stored on your laptop? If yes, encrypt them. Are there any unused AWS IAM access keys? If yes, delete them. Have AWS IAM access keys been rotated? If so, have you checked the time frame? Have you ensured whether any IAM Master and IAM Manager roles are active within your AWS account? If no, do it. Are there any deprecated AWS IAM managed policies? If yes, correct them. Have you stored the root password somewhere safe? We recommend using a federated login tool, like Okta, for better login credentials management. Do you have Admin role for day-to-day operations? If no, create one. Are there any AWS IAM groups that have inline policies attached? If yes, delete them. IAM groups must use managed policies for better control. Are there any over permissive AWS IAM policies attached to IAM roles? If so, recheck permissions. Are there any under permissive AWS IAM policies attached to IAM roles? If so, recheck permissions. Have you removed IAM policies with full administrative privileges? If not, do it. Are there any inactive AWS IAM users sitting for a long period of time? If yes, delete them. Have you configured IAM policy for EC2 IAM roles for app tier? If not, do it. Have you removed expired SSL/TLS certificates from AWS IAM? If not, do it. When was the last time you rotated AWS IAM SSH public keys? Are CloudTrail logs setup? If not, do it. Are you using either MFA or external IDs for cross-account IAM roles? If not, do it. Have SSH keys and IAM keys been rotated for everything? If not enable automatic key rotation. Have you attached policies to groups instead of individual users? If not, do it. Have you checked power users’ account activity lately? If not regularly do it. Are policy names reflecting policy’s function? If not, do it on a regular basis.


There are several auditing tools like Security Monkey, CloudCustodian, etc. available today to perform security auditing checks.


But today’s cloud infrastructure are robust and involve mapping hundreds of data points and checks. This is overwhelming for a human mind. What we need is a visual console that can encapsulate all this data and present it in an easily consumable form.

TotalCloud Inc. has rolled a new Security View that will provide visual cues to security loopholes in real-time and in 3D space. Sign-up to try. Want to know how the visual cues to security renders, read this post.

Check out this video that gives a gist of AWS Security Group View:

Want a quick demo? Click here.

As a cloud security practitioner, how are you using IAM as a primary control mechanism? Do share your views.

Related Reading:

5 Not-to-Ignore Best Practices for AWS NACLs (Network Access Control Lists)

5 Not-to-Ignore Best Practices for AWS Security Groups


AWS Workflow Automation

TotalCloud automates actions on AWS resources and services using its unique cloud graph engine.

Sign up for a free trial

Top Categories
Stay up to date on the latest stories case studies and videos