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.
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:
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.
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.
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.
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.*
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.
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.
.png)
.png)
.png)
.png)
.png)
