Published : 08.22.2023
Last Updated : 09.21.2023
Identity and Access Management (IAM) policies play a pivotal role in controlling access to resources and ensuring the security of Amazon Web Services (AWS) environments. AWS offers two distinct types of policies: Identity-based policies and resource-based policies – both different in nature and their respective use cases. In this blog, we will delve into the concepts of identity-based and resource-based policies, compare their scope, and explore how they work together to secure your identities and access.
Inadequate access controls and poorly defined policies can lead to unauthorized access to sensitive assets, putting businesses at risk of breaches and compliance violations. A recent report from the Enterprise Strategy Group found that:
It is apparent that properly addressing access management challenges through well-defined policies is essential for maintaining the integrity of AWS environments and by extension, business continuity.
Before diving into Identity-Based and resource-based policies, it’s essential to understand some key IAM concepts:
At its core, the difference between these two policies is that Identity-Based Policies are attached directly to IAM users, groups, or roles and define their allocated permissions. resource-based policies are attached to a resource defining who can access it and perform what actions.
Identity-Based Policies generally provide broader access control as they apply to multiple resources for a specific IAM entity, whereas resource-based policies offer fine-grained control over individual resources. They specify Principals (including specific IAM users) and conditions, allowing resource owners to manage access more precisely.
Most simply, when you want to define ‘what they can access’ you use Identity-Based Policies, and when you want to define ‘what can access this’, you use resource-based ones. The most common example for resource-based policies is when using Amazon S3. In this case, you’d create a bucket policy that details exactly under what conditions a specific user or role can access it and perform a specific action. S3 also allows for Identity-Based Policies of course, for example, offering an identity the following managed policy:
Here we see an identity granted wildcard permissions via ‘*’ to the S3 service on any bucket. In other words, this policy allows an identity to perform any S3 permission on any S3 bucket.
resource-based policies have a specific structure and syntax. resource-based policies are written in JSON format, comprising policy version, statement, effect, action, resource, and condition elements.
The policy version indicates the language version, the statement includes the access rules, the effect can be “Allow” or “Deny,” action specifies the API operations allowed or denied, resource denotes the target AWS resource, and conditions are optional constraints for policy evaluation. To see these elements in action, see the following example:
In this case, we see a policy set to an S3 bucket, granting the permissions “s3:GetObject” and ‘S3:PutObject” to only a specific user coming from the specified IP address.
AWS uses a logical evaluation of policies to determine whether access should be granted or denied based on factors such as resource ownership, request context, and permission boundaries. Here’s a little chart to help visualize the process:
There are some limitations to AWS logical evaluation of permissions and access. This flowchart kind of glazes over it, but that bubble on ‘evaluating all applicable Identity-Based and resource-based policies’ is a BIG order. It assumes that there is insight into all the identity and resource-based policies affecting any given identity – plus, what about organizational controls or guardrails? And what do wildcard permissions like ‘*’ actually translate into?
A lot of the time, organizations struggle to understand how identities hold abilities that teams never intended to directly assign to them. While you may expect it, your cloud service provider doesn’t always have granularity of insight to see possible covert or indirect permissions an identity can get ahold of. For that, you need a cloud security platform with deep permissions and access analytics that take into account every possible permission at the organizational, identity, and resource-based level.
Learn more about Sonrai’s patented Toxic Permissions Analyzer and how it analyzes every possible permission every identity holds to detect risky combinations creating unintended access paths.
resource-based policies have various use cases. Some of the most common are:
AWS resource-based policies offer several advantages, such as:
While resource-based policies are valuable, Identity-Based Policies offer unique advantages too, including:
To ensure robust security and access control, follow these best practices:
Limiting Permissions: Assign only the necessary permissions to users, groups, or roles using the principle of least privilege. Anything that is not necessary to an identity’s job function should not be assigned.
Limiting Access: Conversely, the principle of least access starts at the resource, data, or application itself, and enforces only those entities that absolutely require access be granted it.
Reviewing Policies: Ideally, organizations should regularly audit their cloud, and review IAM policies to maintain a secure and up-to-date access control configuration. Periodic reviewing is not enough because of the cloud’s ephemeral and dynamic nature. Anomalous identity or access behavior or a configuration change can appear as a quick blip, but could be the reason your cloud is breached. The ideal solution is leveraging a cloud security tool offering continuous monitoring.
Separating User Access from Application Access: Differentiate user access for day-to-day operations from application access to improve security and manageability.
For more comprehensive IAM best practices, see 12 Cloud IAM Best Practices.
AWS IAM does an excellent job of providing ways for organizations to structure their permission and access control via Identity-Based and resource-based policies. The issue is the complexity of permissions in the cloud. Permissions function in somewhat of a hierarchical nature with some overriding others. There are organizational permissions, identity-based ones, and resource based ones, all conflicting and creating a net result not always easy to see.
The net result is often unintended access to resources and data via attack paths that bad actors can exploit after some recon in your cloud.
Sonrai Security offers advanced permission analytics that compute every possible action and access point every identity in your environment holds – no matter how many confusing policies, trust relationships, and cross account access points are involved.
You can learn more about Sonrai’s CIEM technology, and how we analyze resource-based policies, identity-based policies, and much more, to reveal attack paths to your data.
A resource refers to any AWS entity that identities can work with, such as an S3 bucket, EC2 instance, or Lambda function. A resource is a necessary component of a resource-based policy.
A resource-based policy is a policy attached to a resource offering fine-grained control over what and who can access it, and what actions they can perform on it. Resource-based policies offer security controls and protection to resources.
An identity-based policy is an IAM security measure that defines exactly what specific users, groups or roles can access and do in a cloud environment.
The differences between resource-based policies and identity-based policies are: resource-based policies are set to a resource to offer fine-grained control over what entities can access it, whereas identity-based policies are attached to IAM users, groups, or roles, to specify what they can access and do.