Before we get started with best practices around using AWS IAM, let’s get our head around some underlying concepts and risks associated with “not getting IAM right”.
Though this post uses AWS IAM as a reference point, readers & security practitioners can draw a parallel to other public cloud IAM implementations as well.
AWS Authentication & Authorisation Work-flow
More details around IAM can be found here:
Identities, Roles and Groups
AWS identities essentially consist of two types – programmatic or user / console. Groups are needless to say, a collection of users that are in turn granted a certain level of access at a group level.
IAM roles need a special mention here, since these are “assumed identities” that get associated with various AWS resources in order to authenticate them to other AWS services with the same account or even a different account.
Let’s now take a look at what can go wrong here and how:
- Over-provisioned vertical access – just like any other access management disaster, loosely configured access or “AWS Policies” can be the starting point to “privilege escalation” in the public cloud space. In other words, once a user has taken on an over-provisioned or privileged role, it would be in a position to perform any action listed as allowed in the respective policy.
Let’s take an example, the below policy allows an IAM identity to perform ANY action on EC2 – including start / stop, terminate instances. We should be careful while creating policies especially ones that grant “Full” access.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "arn:aws:ec2:ap-south-1:111122223333:instance/*"
}
]
}
The above policy allows an entity to perform any action on the instance including terminating the instance.
Similarly, below is an example of a poorly configured S3 access permission that allows an entity to perform ANY action including removing encryption and even deleting the bucket.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "arn:aws:s3:::bucket/*"
}
]
}
- Broadly used roles – A common mistake (or rather convenient overlook) that many practitioners end up making is using a common set of roles across a large scale production deployment. For example, a role that grants access to production S3 buckets and SNS notifications, but does not restrict or segment access by operating requirement. In case a service or resource with this role is compromised, the adversary would gain horizontal access to ALL production services, rather than maybe just the ones required by the compromised service.
Below is an example of a policy that gives Get Object permission to every bucket object present in an AWS account. If this is attached to a role, then that role can access any object present in any bucket.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "*"
}
]
}
Now that we have your attention, let’s jump straight into some AWS IAM best practices, which are the building blocks of public cloud access control, and if not done right at the start, can result in significant cost at a later stage.
Basic IAM Best Practices
- Disable root account – create a separate account for administrative access, and avoid using the root account
Find more about root account usage here - MFA for privileged account login via console – enable multi-factor authentication via SMS or soft token for ALL privileged users to avoid stolen credentials from being mis-used
- Password policy enforcement – ensure the configured password policy enforces the use of complex passwords (a mix of upper / lower case letters, numbers, special characters and password expiry)
You can find more information in detail about AWS Password Policy here - Limit access key usage – access keys are the keys to your kingdom, we should ensure these are used sparingly and with very close control and monitoring. Should be avoided in production unless absolutely required. Creating an access key for administrative tasks is asking for trouble right there, use IAM roles instead
- Access key rotation – in case access keys are used, these should be rotated periodically so as to limit the exposure in case of a leak
- Usage of groups and avoiding inline policies – users should be associated with groups and in turn IAM policies to grant access to AWS resources or services, however, one should avoid using inline policies since these get difficult to track and audit at scale
IAM Best Practices for Large Enterprises
- Federation / SSO – large sets of user accounts are always difficult when managed in a de-centralized manner, public cloud or AWS identities are no different! In case your organization uses a significant user-base on AWS or any public cloud setup, SSO should be the preferred mode of authentication
- Access segmentation – like we discussed earlier, as a best practice, try and create separate IAM roles or policies for services that need different levels of access
- Limit cross-account access – a need will often occur for an organization to grant external AWS accounts access to it’s resources or services, this can be achieved via “Trusted Relationships”. While working with these configurations, ensure granular access is created rather than allowing broad access to source identities or target resources
What is Cross Account Access? Find here - Monitor – use CloudWatch or an SIEM to setup alarms for:
- Root account usage – whenever the root account is used to access the console or AWS services.
- Privileged account or group changes – addition to admin or privileged user groups; and creation of privileged accounts
- Access key leakage – use repo scanning tools to scan internal as well as public code repositories for accidental leakage of AWS security credentials.
Processes
Public cloud environments are pretty dynamic and it is imperative to not only govern critical changes but also monitor the environment for any deviations from security baselines.
- Provisioning – leverage workflows to intercept any sensitive changes to your AWS environment and review them to ensure they don’t adversely impact the access guardrails. For example addition of inline policies, role or group permission modification, cross-account access
- Periodic review – use CSPM solutions to keep a check on your IAM security baseline, enable notifications whenever a critical or high severity check goes non-compliant.
AWS Services for Strengthening IAM
- Access Analyser – as the name suggests, analyses AWS IAM policies and roles to call out potential issues https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
- Organisation SCPs – one can use service control policies at an organisation level to establish the maximum permissible access granted to an IAM identity requesting access to organisation resources
- Permission Boundaries – are a useful feature to create a broad level outer limit of access that an IAM identity would be entitled to. This helps eliminate or reduce the impact of IAM over-provisioning
- GuardDuty – monitors AWS API activity via CloudTrail to detect abnormal IAM activity, resource access to call out early signs of a compromise. Find more about GuardDuty findings for IAM.
AWS IAM and Cy5
All of the mentioned best practices can be monitored by Cy5’s CSPM offering from the point of posture management as well as real time threat detection.
ion offers more than 20 checks dedicated only to the AWS IAM service, making it super convenient to keep a watch on posture and threats and nonetheless, have a general sense of visibility spanned over all the features that IAM offers.
Some of them are:
Our Cloud DataLake feature could also help in achieving a quick visibility over the cloud, just using basic SQL queries, nothing fancy!
We hope this post around AWS IAM best practices was helpful. Re-iterating – IAM done right early, goes a long way in saving operational costs & time at a later stage!
