AWS security can get really complicated, really fast. If you're a newbie to developing on AWS or still learning cloud security, the best place to start is by understanding the basics of AWS Identity and Access Management (IAM).
In this article, we're talking about IAM identities. Specifically, we'll be looking at users, roles, and groups in AWS IAM, how each of them work, and how to secure your AWS resources by managing these identities.
We'll also explore some security best practices when dealing with permissions, access control, and short term vs. long-term credentials.
A root user is the highest level of user in your AWS account; essentially the 'super admin' user. Root users have full, unrestricted permissions to access AWS resources, modify permissions for users and roles, and any other actions within the environment.
You should NEVER use your root user for any day-to-day activities, even administrative ones. Only use it for the most essential tasks that can only be performed with root permissions (such as changing account settings, restoring IAM user permissions, etc).
Ideally, you should create your first IAM user, then securely encrypt and lock away the credentials for your root user.
Users are the most basic IAM identity, and represent a person who can access resources within your AWS environment. A user can also be an application that can access those resources; for example, a microservice that fetches a customer's account information from your database.
By default, a user has no permissions to perform any tasks. When creating your first user, you can give them certain administrative permissions so they can create and manage other IAM users, groups, and roles.
Take a deeper dive into AWS IAM with our hands-on course! Start learning today.
User Groups in IAM simplify the process of giving permissions to users. Instead of assigning permissions individually to each user, you can create a group and assign permissions to that. You can then add users to that group, which automatically gives them the permissions assigned to the group.
For example, if you want to assign admin privilege to a user 'Dave', you can just add Dave to an 'Admins' group that has the right set of permissions. If Dave's responsibilities change at any point, you can simply remove him from the group, and he'll lose the specific permissions granted by the Admins group.
One user can belong to multiple groups. However, groups can't be nested, ie., one group cannot contain another.
Roles are similar to users, in that they represent a single identity (person or application), and you can assign it permissions to access resources within AWS. However, they have one key difference: they're not tied to one specific person/application.
Think of it like this: a user is like an identity card — it belongs to one person. It can only give that one specific person access to AWS resources. In this example, user 'Carla' only has access to S3 and Lambda.
A role, on the other hand, is like a temporary access pass. You can assign a role to any user for a temporary task, and once that task is complete, revoke access to that role. Let's say Carla is asked to help out on a project involving EC2. Carla's team leader can assign her a role with the appropriate permissions. Once she's done, they can simply revoke her access to the role itself.
Roles use temporary credentials, which means they don't need you to store or encrypt passwords or access keys. This makes them a far more secure option to give users and services access to resources in AWS.
For this reason, roles are often used to delegate access to users and apps that don't normally have access to your AWS resources.
Permissions in AWS IAM are additive, which means there's only 'Allow' rules, and no 'Deny'. By default, an IAM identity has no permissions or privileges.
This isn't by accident! Your approach to managing access should be to follow the principle of least privilege: give the fewest permissions possible for the user/role to perform their task.
Users rely on long-term credentials to get access to your AWS environment. However, these can pose a serious security risk since they can be compromised. If an attacker manages to get their hands on a user's credentials, they can get access to your AWS resources, modify or steal data, and install malware without even being noticed.
The solution? Identity federation! This involves using an Identity Provider (IdP) to authenticate users and give them access to your AWS. The biggest advantage of federated access is that it eliminates the need for passwords and access keys, using temporary credentials exclusively.
AWS supports commonly used open identity standards, including SAML 2.0, OIDC, and OAuth 2.0. For your customer-facing web applications, you can use Amazon Cognito, which supports signing in with identity providers like Apple, Google, Facebook, Amazon, etc.
Access keys are long-term credentials, which makes them more susceptible to compromise.
Make sure to regularly rotate and remove your access keys in order to avoid them going stale over time. Rotating them every 90 days or so should be good enough.
If stale credentials are bad, old and unused IAM identities are worse. An old user or role is a sitting duck for attackers to find and compromise. And if that happens, it's next to impossible to detect their activity, since the monitoring service sees them as just another user.
Make it a habit to watch out for users, roles, and policies that have gone unused for an extended period of time. If it has no immediate utility, it's safer to remove it.
Learning the basics of AWS security is just the beginning. Cloud skills are at their highest in demand right now, and becoming an AWS security pro can help you earn more, advance your career faster, and be the MVP on your team.
AppSecEngineer offers 8 amazing courses that feature hands-on labs that let you learn complex concepts and reinforce them with real-world exercises.
You can even try our Playgrounds, which are CTF-style exercises where you solve security problems in realistic labs and cyber-ranges. These are designed for users who want to test their skills in AWS security.
All that and much more is available with a single subscription on AppSecEngineer. Get your account and start learning today!
Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.
Contact Support
help@appsecengineer.com
1603 Capitol Avenue,
Suite 413A #2898,
Cheyenne, Wyoming 82001,
United States
.svg)
.png)
.png)
.png)
.png)
.png)