July 6, 2023

What is identity and access management for AWS?

Identity and access management (IAM) is a tool that can help you wield full control over who can access your AWS services and resources, and what they can do with them. Applied to your AWS organization, IAM can grant (or refuse) access to your AWS accounts and/or cloud applications, and can use the same credentials as other standards-based services.

IAM Identity Center was rolled-out by Amazon in 2022 as a replacement for their previous AWS SSO (single sign-on) service. It includes the same functionality as AWS SSO, plus a whole lot of other capabilities that the older SSO solution didn’t have. Most importantly, it enables you to manage complex access privileges from a centralized place. 

In this article we will discuss the importance of IAM, benefits, common pitfalls, best practices and we share some of our open-source modules and resources to help you get started.

Why not just use single sign-on (SSO)?  

Single sign-on (SSO) gives you access to multiple services using a trusted set of credentials. This is useful for a number of reasons, including the fact that AWS is a vast galaxy of resources and services - so a single point of access for all of them is pretty convenient.

However, SSO doesn’t define what users can do, see, or access. For this you need more granular control that defines access based on identity and role. This can also be extended to non-human users like services or workloads.

Why is identity access and management (IAM) important?

To give the simplest answer to this question, AWS IAM forces users to adopt best practices which keep the entire infrastructure more secure. 

Cloud services are complex, and subject to wide-ranging risks which aren’t always immediately apparent. While we would like to think that people now grasp the importance of good security practices, human nature still pushes people to make easy decisions instead of ‘best’ ones.

Security breaches are still commonplace. According to Verizon’s 2022 Data Breach Investigations Report (DBIR), the most common method used by hackers attacking web apps was the use of stolen credentials. This means that it’s vital to limit what any one user can access, view, and do with your AWS resources and services.

Maintaining robust security with AWS IAM is one way you can keep cyberattacks at bay, and de-risk your enterprise from the potential costs and lost business resulting from a security breach or leaked data.

It’s also essential that your identity and access control is managed in an organized way - from a centralized place - as this helps give a clear overview even when things get complicated. And they will. 

The benefits AWS IAM can offer your cloud environment

One of the great things about AWS IAM is it doesn’t cost any extra for you to use. Compared to the potential costs if you don’t use it (i.e., everything), this is a good deal. 

AWS organizations enable your organization to add an unlimited number of new users, so it's essential to keep tight control over what each one is allowed to view, access, and do. A huge benefit of IAM is it helps to support hybrid work with cross-device access, because users in your AWS organization can use the same SSO credentials across multiple devices, while still being limited in terms of potential damage (in case the credentials are misused).

Without a single identity provider (like SSO or IAM) for the organization, organizations can unwittingly create multiple identities/user accounts for each distinct user. Making sure these are kept up to date gets increasingly difficult over time. By using IAM for AWS, organizations make the on-boarding and off-boarding process easier and increase the built-in security of their systems. It also works smoothly with other standards-based identity providers like GSuite, Okta, and Azure AD, to name a few.

Because IAM is a centralized web service that covers all your AWS organization’s infrastructure, it’s easier to update privileges across all your organization’s services and resources at once. This saves significant time and effort, especially as you scale up, start using more services and adding more users.

The use of identity and access management is also essential for services that need to meet regulatory requirements, for example in case you need to provide payment card processing or HIPAA compliance.

One of the best things about IAM is that it can be very ‘fine-grained’ when it comes to control. It enables you to set very specific rules that restrict access to specific identities and roles. This level of ‘need-to-know’ access ensures a high level of confidentiality, and limits the risk that any one user account presents to the organization by limiting what they can do.

While we tend to focus on the threat of malicious external cyberattacks, by strictly limiting access and privileges you limit the potential for inadvertent errors. Without these guardrails, it would be too easy for an incompetent user to interfere with things they shouldn’t and make changes with unforeseen consequences.

By using AWS IAM Identity Center as the ‘front door’ to all your AWS services, your organization can create an atmosphere and culture of security, and this encourages secure behaviors. However, it’s still absolutely essential to regularly revisit the ‘basics’ of good security, and help users keep their credentials secure and updated.

Common pitfalls when configuring and using AWS IAM

To be clear, using AWS IAM is a good idea. But it must be done right. Everyone needs to be on-board, from the management team right down to the most junior of developers.  

The reality is that IAM can be hard to manage when you don’t already have experience and expertise. This is especially true when things get more complex, as even a basic misconfiguration can be a huge problem if left unchecked.

Lax security

AWS IAM isn’t a magic cure for security woes. It still needs to be combined with standard security best practices like strong passwords, and regular password changes. Service control policies (SCPs) are another tool that can add an additional layer of protection by defining set limits to what member accounts from your organization can do.


Implicit denial (=possible access)

A mistake that people sometimes make is to not use explicit ‘denies’, and using implicit denies instead. This can result in users being able to give themselves privileges you’d perhaps prefer they did not have, so always use explicit denies as a rule.


Misconfigured S3 buckets

Another common problem is when S3 buckets are misconfigured, with an open registry that’s visible to all users. Your S3 buckets must be exclusive, with a dedicated object owner who manages (proxied) access to objects using IAM (and not access control lists).


Not using role-specific user accounts

The value of IAM comes from its ability to get specific about giving access and privileges to specific users and roles. However, human nature prefers short-cuts, so we often see people using one ‘general’ account for multiple roles, services, and resources. While this might be more convenient, this undermines the strength of compartmentalized identity and access management.


Passive management

It’s more important than ever for you to continuously monitor and evaluate current configurations and (external) access. There are several tools that can help you with this, including AWS config, AWS Access Analyzer, and AWS CloudTrail. It’s also good to keep track of which ports are open, and make sure they need to be.


Best practices for using AWS IAM in the most secure way

There are some simple best practices you can apply to your organization to ensure that AWS IAM gives you the best protection.


Keeping the root user exclusive

Your organization’s first AWS account is the ‘root user’. Keep this user account entirely separate, and use it only for admin-role tasks and IAM controls. Don’t use your root user account to access AWS.  Keep this user account secure by safeguarding credentials with MFA (see below) and don’t use access keys for the root user. Too much is at stake!


User hygiene

Regularly review and remove any users, roles, and permissions not in active use. This will cut down the number of users and roles you need to manage and ensure that access is better secured. This is much easier using a centralized IdP (identity provider) like IAM. 


Require MFA for IAM users

Multi-factor authentication (MFA) is an important component of your IAM security. Use MFA for any IAM user accounts and your root user account. For other users or workloads/services that need access to AWS resources or services, assign these as IAM roles so access remains temporary and tightly controlled.  


The least privilege principle

Always grant only the permissions required to fulfill the specific task by defining the ‘least privilege permissions’. If this isn’t immediately apparent, start with broader permissions and then your CloudTrail access logs to see what is being used for specific tasks/roles. This is made easy with the IAM Access Analyzer tool, which can generate granular IAM policies using this data. Then you can test and roll-out these policies. Especially useful for non-human users, where access activity is more well-defined.


Efficient and granular control

Identity and access control helps your AWS organization retain a high level of security, even as you scale up with additional services, resources, and users. It’s easier to manage this complex challenge with a centralized service, and this reduces both your workload and the potential for error.

Setting up your AWS IAM is relatively simple to start with, but as your project grows it will become more complicated. You may need to manage a growing number of external users, as well as services or workloads. All of these need to be correctly configured in IAM, and be kept continuously updated. Because the implications are not always clear until something goes wrong, it’s a huge advantage to have someone with extensive AWS IAM experience to help.

As a cloud development company, we feel the importance of sharing our knowledge with you and we are happy to do so. On the AWS IAM topic, you can use our open-source module on Github, for example. It will provide guidance at the start, managing or growing your IAM. Or you can consult our other resources on our website.

If you are in need of more elaboration, let’s get in touch and talk about your project. We always see a way how we can help it soar to new successes.

Let’s fly!

Lets’s fly together! Contact us
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.