8 mins to read
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 IAM policies – both different in nature and their respective use cases. In this blog, we will delve into the concepts of an AWS resource based policy vs identity 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:
- 40% of respondents failed a compliance audit due to cloud entitlements with unmanaged, unneeded access permissions.
- And 99% of the organizations who experienced a security breach recognized identity credentials played a role in the breach.
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.
Key IAM Concepts:
Before diving into Identity-Based and resource-based policies, it’s essential to understand some key IAM concepts:
- IAM User: A representation of a person or entity within AWS, allowing them to interact with AWS services.
- Groups: A collection of IAM users that share common permissions.
- Actions and Permissions: Actions represent individual operations, and permissions define what actions are allowed or denied.
- AWS IAM Role: An entity you create and assign specific permissions to. It can be assumed by other trusted entities like machine or human identities.
- AWS Principal: Only in resource-based policies, it’s a human or machine identity that makes requests to a resource.
- AWS Service: The tools or solutions provided by AWS and accessed by identities to operate, secure, and scale your cloud.
- Resource: Any AWS entity that identities can work with, such as an S3 bucket, EC2 instance, or Lambda function.
- Condition: These specify the times an IAM policy is in effect based on factors like time, IP address, or requested action.
AWS Resource Based Policy vs Identity Based:
Objects of Granted Permissions
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.
Access Granularity:
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.
Use Case
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.
Understanding the Structure of an AWS Resource Based Policy:
General Structure and Syntax:
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.
JSON Policy 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 Logical Evaluation
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.
Common Use Cases for AWS Resource Based Policies:
resource-based policies have various use cases. Some of the most common are:
- Enforce Resources Protection: Restricting access to critical resources to prevent accidental modification or deletion. Because resource-based policies offer far more granular control, they are a great way to enforce stricter access protection. These restrictions reduce the chances attackers can access and exploit resources and data.
- Cross-Account Access: Enabling a principal to access specific resources in a different account. The original account with the principal is the trusted account, while the account hosting the resource is the trusting account. To complete cross-account access you need to attach a resource-based policy to the resource you intend to share (you also must use an identity-based policy on the identity making the request.)
- Broad Access Guardrails: Implementing organization-wide policies to govern access to shared resources. A great example is a global IAM condition key. It is essentially a shortcut to allowing services to access resources. The condition simplifies how services interact with resources. An example from AWS is a condition key used to implement a bucket policy that limits access to your data from your VPC while safely granting access to an AWS service, such as CloudTrail.
Benefits of Using AWS Resource-Based Policies:
AWS resource-based policies offer several advantages, such as:
- Simplified Access Control: Resource owners can delegate specific permissions to identities, groups, or accounts, promoting a streamlined access management process.
- Fine-Grained Control: Allows granular control over individual resources, minimizing potential security risks.
- Scalability: Offers an efficient way to manage access to resources, especially in complex AWS environments.
Benefits of Using AWS Identity-Based Policies:
While resource-based policies are valuable, Identity-Based Policies offer unique advantages too, including:
- Dynamic Permissions: IAM users or roles can be granted permissions based on user attributes or conditions.
- Integration with Third-Party Providers: IAM allows integration with external identity providers for single sign-on (SSO) and enhanced authentication.
- Monitoring of Identity Activity: IAM provides logging and monitoring capabilities to track identity actions and detect suspicious behavior.
- Integration with IAM Features: IAM enables integration with other AWS services like AWS Organizations and AWS SSO for centralized identity management.
Best Practices for AWS IAM Policy:
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.
Learn about Sonrai’s Cloud Detection and Response solution.
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.
Building Policies to Secure Permissions and Access?
If you’re endlessly writing identity-based policies or resource-based policies, there is an easier way. What if you could deploy one global policy to secure the most sensitive permissions and lock down AWS services your teams aren’t using?
The Sonrai Cloud Permissions Firewall analyzes what permissions your identities are using and what cloud services and regions are used. Everything that is unused can be instantly secured with a single global policy you deploy.
- Excessive permissions are restricted
- Unused services and regions are disabled
- Dormant identities are quarantined
This protected state is ongoing with a default deny, and any new access or services needs are granted through an automated permissions-on-demand workflow. Policy management is handled, on us.
FAQs
What is a resource in AWS policies?
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.
What is 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.
What is an identity-based policy?
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.
What are the main differences between resource and identity policies in AWS?
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.
Can you mix Identity-Based and Resource-Based Policies for the same AWS resource, and if so, how does AWS evaluate the combined policies to determine access?
When AWS processes both Identity-Based and Resource-Based Policies for a single resource, it follows a specific evaluation logic to determine whether to allow or deny an action. AWS evaluates all permissions policies, looking for any explicit DENY statements. If one is found, the action is denied regardless of any ALLOW statements. If no explicit denies are present, AWS then checks for ALLOW statements. The evaluation doesn’t stop at the first match; it considers all policies applicable to the request context, ensuring a comprehensive assessment of permissions.
