Protect your AWS workloads from threats with our curated bundle of security best practices. Gain insights into S3 security, security group management, and more to ensure the confidentiality, integrity, and availability of your data.
AWS identity and access management (IAM) is the authorization and access control mechanism that governs which users can access specific AWS resources and which actions they can perform. When a user is authenticated, IAM acts as the main guardrail to prevent unauthorized actions and resource exploitation. Simply put, IAM maintains integrity and confidentiality across an AWS environment.
Authentication process: This process begins when a user sends a login request to an API endpoint on AWS API Gateway. The request is then routed to AWS Cognito, which is responsible for handling authentication. Cognito verifies the user's credentials and, with successful authentication, issues access and refresh tokens, managing the identity lifecycle of the user.
Authorization process: Once a user is authenticated, the API Gateway, configured with a Cognito User Pool Authorizer, validates the access token. (The valid access token contains claims about the user, such as identity and group memberships.) After successful validation, the process proceeds to authorization, which is managed through AWS IAM. Based on the group memberships and other claims, IAM roles are assigned to the Cognito groups. These roles are predefined with policies that specify permissions and limit access to resources.
IAM plays a central role in defining and managing security permissions and access policies, which is why it’s a key attack surface.
Incidents like those at Deloitte, eBay, and Home Depot show that company size doesn’t matter; a simple misconfiguration or social engineering attempt can cause large companies to lose millions of dollars. That’s why it’s crucial to understand common misconfigurations and to strengthen your overall security posture by following best practices and using available tools.
In addition to understanding the authentication and authorization processes, it’s a good idea to have a sense of the key components and concepts of AWS IAM:
The root user is the initial account set up when you first register for AWS and has maximum permissions to all AWS services and resources. (It’s a good idea to limit the use of the root account and instead operate through individual user accounts with minimum necessary permission granted for everyday tasks.)
IAM users refers to either people or services with a permissions boundary to access AWS resources. Each user can be equipped with distinct security credentials.
IAM roles are used to grant specific permissions to users, groups, applications, or other AWS services. Essentially, roles provide temporary credentials that are used to make API requests or access resources. This setup means there’s no need for permanent credentials, enhancing security by limiting long-term access risks.
IAM groups area way to assign permissions to multiple users simultaneously. Each user in the group automatically inherits the permissions assigned to the group.
Federated users describe identities that are managed outside of AWS but are allowed to access AWS resources. These users are typically part of an identity system external to AWS (e.g., Microsoft Active Directory).
Policies are objects that, once linked to an identity or resource, determine permissions for that entity. These policies can either permit or prohibit actions involving resources.
A closer look at AWS IAM roles
IAM roles are not uniquely associated with a person (the way they are for IAM users). There are four entities that may assume IAM roles:
Users from the same AWS account can use role-based access control to manage permissions within the organization.
Users from different AWS accounts are granted cross-account access, allowing them to interact without the need to create new user accounts.
AWS services, like EC2, use IAM roles to access additional AWS services securely.
Federated users benefit from identity federation, which integrates an external identity provider with AWS.
Unlike users and groups, IAM roles have temporary credentials which will be destroyed/ reinitiated after each role session.
IAM roles involve two policies: a trust policy for authentication and a permissions policy for authorizing the actions that the role can take within AWS:
Trust policies specify which principals (such as users, other roles, or AWS services) can assume the role. Its primary purpose is to establish trust between the role and the principal attempting to assume it.
Permissions policies specify the actions that the role is authorized to perform once it has been assumed by a principal.
Common misconfigurations in IAM roles
Misconfigurations can happen for all sorts of reasons, such as complex system architectures, human oversight, or gaps in technical knowledge. Even basic errors, like failing to revoke access to users who are former employees, can cause catastrophic damage. These vulnerabilities provide opportunities for malicious actors to infiltrate and exploit the system. Remember: Misconfigurations can happen anywhere, but IAM misconfigurations are particularly significant because IAM defines the guardrails for organizational data and services.
Luckily, there are best practices to help you make the right foundational architectural decisions. So what types of IAM role misconfigurations typically occur, and what best practices should you follow?:
Unused IAM roles: A 2023 Microsoft report shows the widening gap between permissions granted and permissions used: Only 1% of the permissions granted to cloud identities are actually used. Because unused roles can provide easy targets for malicious actors, pruning them is an easy way to reduce your attack surface.
Overly permissive roles: If roles with too many permissions are compromised, the identities associated with them could access other systems. The effect? Threat actors could potentially modify or delete critical resources. To avoid this risk, follow the principle of least privilege.
Static IAM role keys: When IAM roles use static access keys that are not rotated regularly, it increases the risk that these keys will be leaked or misused. That said, manual key rotation can introduce complexity and human error. Your best bet? AWS Security Token Service (STS) automates the process of managing temporary credentials.
Not using condition statements in role policies: Condition statements add an extra layer of security because they spell out the conditions that must be met for IAM policies to grant permission. Without condition statements, permission boundaries can be too open. (For example, your system might allow actions from any IP or location).
The confused deputy problem in cross-account access: This problem happens when a less privileged entity (a “deputy”) is manipulated by a malicious actor into performing actions that benefit the attacker. To nip it in the bud, use an external ID known only by the customer, along with a trusted AWS account.
Direct assignment of IAM roles to instances: Passing IAM roles directly to an instance in situations where services need to interact with each other could expose you to security risks. Instead, use service roles (which are specifically designed to let an AWS service interact with required AWS resources), and service-linked roles (roles predefined by AWS to provide services with exactly the permissions they need to operate).
Beyond best practices, take advantage of tools that automate IAM auditing and provide fine-grained control over access to AWS services and resources:
AWS IAM Access Analyzer: You can use this tool to detect permissions that accidentally allow external access to your AWS resources. It also generates reports so you can confirm IAM roles are tightly controlled and adhere to the principle of least privilege.
IAM Identity Center: Through the IAM Identity Center, you can manage IAM roles and user permissions across AWS services and accounts.
AWS identity federation: Identity federation enables establishing trust relationships between external identity providers (IdPs) and AWS environments. With that relationship in place, users can authenticate and assume IAM roles through their existing organizational credentials / IdPs. Keep in mind that these external IdPs need to be compatible with OpenID connect (OIDC) or security assertion markup language (SAML).
AWS CloudTrail: CloudTrail captures detailed logs of all IAM-related actions, such as changes to roles or policies, which you can use to find unauthorized changes.
IAM policy simulator: The IAM policy simulator is a great way to test the effects of IAM role policies before deployment.
Aside from AWS’ native solutions, there are specialized tools for cloud infrastructure entitlement management (CIEM) that focus on the management and security of identities and access entitlements within cloud environments. These third-party tools often provide broader visibility and control over identities and policies and even work for multi-cloud environments. For example, Wiz stands out because of its cross-platform coverage and its ability to automate remediation across cloud environments.
Navigating AWS IAM roles can get complex, but getting them right is crucial for keeping your AWS resources secure. From avoiding overly permissive roles to staying on top of key rotations, the stakes are high. After all, even a small oversight can lead to significant vulnerabilities. To avoid risks and headaches, choose CSPM and CIEM tools that help streamline IAM role management and enhance security measures.
That’s where Wiz comes in. Wiz provides a clear view of your IAM configurations and actively helps tighten your cloud’s security, ensuring you’re granting only the necessary permissions—and staying compliant.
If simplifying IAM security management while keeping a strong security posture is what you’re after, seeing Wiz in action might just be the next step. Schedule a demo today and see how easy it can be to manage IAM roles with Wiz.
Take Control of Your Cloud Entitlements
Learn why CISOs at the fastest growing companies secure their cloud environments with Wiz.
Shadow IT is an employee’s unauthorized use of IT services, applications, and resources that aren’t controlled by—or visible to—an organization’s IT department.
Vulnerability management involves continuously identifying, managing, and remediating vulnerabilities in IT environments, and is an integral part of any security program.
API security encompasses the strategies, procedures, and solutions employed to defend APIs against threats, vulnerabilities, and unauthorized intrusion.
In this post, we’ll explore some of the challenges that can complicate cloud data classification, along with the benefits that come with this crucial step—and how a DSPM tool can help make the entire process much simpler.