Managing access to AWS environments can quickly become a tangled mess of usernames, passwords, and permissions, especially as your organization grows. With this entanglement comes security threats; what happens if a forgotten user account gets compromised? Would you know what that account has access to, or be able to deactivate it quickly?
Identity is always a difficult problem to solve, but especially so within cloud environments. That’s why it’s important to use a Federated Identity Provider to automatically provision, deprovision, and manage access to cloud resources.
In our second installment on the AWS Top 10 Security Risks, we’ll discuss the #2 priority for securing your Accounts: using a Federated Identity Provider. This series highlights the most common security issues we at Cloud Security Partners have seen in our customers’ AWS accounts, and how to best address them.
IAM Users and the Challenges of Scale
AWS has two distinct user types: the root user (the account owner, with unrestricted access) and IAM users.
IAM users are accounts that can be provisioned with customizable permissions, making them much safer for daily use. While they are convenient to create and use, they have a few major issues:
- Long-lasting credentials: IAM users authenticate with passwords or access keys, both of which are long-lasting credentials. Long-lasting credentials may not expire automatically or at the same cadence as short-lived tokens like OAuth tokens, making them more prone to risks like credential leaks.
- Lack of Central Control: Each IAM user is its own separate entity with its own policies and authentication setup, making them difficult to govern centrally. Different users may require similar permissions, leading to a proliferation of users, or worse, users sharing user identities.
- Gaps in Identity: Privileges change frequently, and keeping all your IAM users updated can be very tedious. Often, IAM users are created and never revisited, leading to legacy users with access to resources they should no longer have.
For these reasons, IAM users are no longer recommended for most use cases within AWS. Federated identities are a much better solution that solves the above issues.
Federated Identities
Federated identities link a user's digital identity from an identity provider (IdP) to roles and privileges across multiple systems.
Within AWS, this means that you can link external identities to temporary IAM roles via protocols like SAML or OIDC, enabling users to assume appropriate permissions without creating standalone IAM users. This approach has several advantages:
The IdP manages identities on your behalf and creates a federated identity using a short-lived token to access services on your behalf. This significantly reduces the blast radius of long-lived credentials being leaked, as short-lived tokens are used instead.
On top of this, federated identities allow you to define roles and permissions centrally and assign them granularly to users. This allows you to map roles and privileges to multiple users at once, even across multiple services and platforms. This helps prevent the proliferation problem previously discussed.
Finally, this approach allows you to govern identities across multiple platforms. If you have multiple AWS accounts or other SaaS accounts, such as a password manager, one login can govern access across all of these.
How to use Federated Identities
Luckily, AWS makes it easy to use federated identities through its AWS IAM Identity Center platform. However, migrating your existing IAM strategy to federated identities can be a large task.
To migrate, follow these steps:
- Select and set up your Identity Provider
AWS IAM Identity Center supports several Identity Providers: the built-in user directory, AWS Managed Microsoft AD, and external IdPs like Okta and Microsoft Entra ID. Select one based on your requirements, and set it up.
- Audit your current IAM landscape
The second step to using federated identities with your AWS environment is to understand your current IAM structure. Ask the following questions:
- What IAM users are currently in place?
- What access keys are currently active?
- How are each of these access keys and IAM users being used?
Group each of the current IAM entities into things that humans need access to, and things that are required by automated workloads. Human users should be replicated in the IdP, while automated workloads should not; they should be granted an IAM role instead.
- Create permission sets
Now that you understand your IAM landscape, each of the current IAM permissions should be replicated with a permission set. A permission set is a reusable collection of permissions (policies) that can be assigned to multiple federated users or groups, defining what resources they can access.
For example, if certain users require audit access to your S3 buckets, their permission set should include AmazonS3ReadOnlyAccess.
- Set up the AWS IAM Identity Center
AWS IAM Identity Center is how you plug your Identity Provider into your AWS account’s IAM system. The console will guide you through connecting your IdP with Identity Center, using SAML 2.0 or OIDC.
Use Identity Center to map the permission sets you previously created to your IdP. This will ensure that permissions are synced with your users, ensuring that permission changes, offboardings, and other changes are respected.
Once this has been set up, you can start using the identity platform to manage access to your AWS environment.
- Delete IAM users and access keys
The last step is to clean up all of the old IAM users. Having fewer accounts floating around will ensure that your AWS environment is safer.
To do this without breaking any functionality, you may want to deactivate IAM users and access keys for a period of time before deleting them. Do this by attaching a policy that denies all actions to IAM users and disabling IAM user access keys, then monitoring your AWS CloudTrail logs for AccessDenied events. If any such events occur, you should redo Step 2.
Once these have been deleted, remove any unnecessary permission sets and monitor your Identity Provider for changes.
After these steps, you should be fully migrated off IAM users and onto the safer solution of federated identities and IAM roles!
Conclusion
Identity and access management in AWS is a difficult problem, but it can be made more manageable by using federated identities. Migrating to federated identities may be a difficult undertaking, but it will substantially improve your security posture. It will help you harden your AWS environment, make administration simpler, and should be the second priority for reducing risk for AWS.
This post is the second in our series on the AWS Top 10 Security Risks: each installment will dive deeper into the most common risks we see across customer environments and how to fix them. Stay tuned for the next blog, and if you’d like expert help evaluating your cloud security, reach out to Cloud Security Partners for a comprehensive assessment of your AWS environment.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
