Resource Policies

Understand access granted by AWS resources themselves.

IAM identity policies answer questions about what an identity is allowed to request. But many AWS services can also define authorization directly on the resource. Examples include S3 bucket policies, KMS key policies, SQS queue policies, SNS topic policies and other supported resource-policy patterns.

This matters because a resource can grant access even when the relationship is not obvious from the principal's attached IAM policies.

Where to find Resource Policies

The current view can summarize:

• total resources represented
• publicly accessible resources
• resources allowing cross-account access

The table provides context such as resource type, resource name or ARN, AWS account, public exposure, cross-account exposure, risk and last seen.

Identity policy vs resource policy

AWS authorization can involve both. This is why a complete access investigation may require looking from both sides.

Principal
   ↓
Identity Policy
   ↓
Permission request
   ↓
AWS Resource

AWS Resource
   ↓
Resource Policy
   ↓
Trusted Principal

Example: S3 bucket policy

A bucket policy can grant another principal permission to access the bucket. The security question is not simply “does the bucket have a policy?” It is: who does the policy allow, what actions are granted, and what conditions restrict the access?

S3 Bucket
   ↓
Bucket Policy
   ↓
External AWS Principal

Example: KMS key policy

KMS authorization is particularly important because encrypted data depends on key access in addition to data-resource permissions. An identity may require both permission to retrieve the encrypted data and permission to use the appropriate KMS key.

Encrypted Data
    +
KMS Key
    ↓
Key Policy / IAM authorization
    ↓
Decrypt capability

This connects resource-policy analysis with Toxic Permission Combinations and Identity-to-Data Intelligence.

Public access

A resource policy can use a broad principal such as Principal: "*". This can create public exposure depending on the allowed action, resource type, policy conditions, service behavior and additional AWS public-access controls.

Cross-account resource access

A resource policy may grant a principal in another AWS account direct access. This differs from cross-account role assumption — the principal may access the resource through the resource policy without first assuming a role in the resource owner's account, depending on AWS service authorization behavior.

External AWS Account
        ↓
Resource Policy
        ↓
S3 / KMS / Queue / Topic

Use Cross-Account Access for the broader account-boundary investigation.

Conditions matter

Resource policies often rely on conditions to narrow otherwise broad trust. Examples of contextual restrictions include:

• source resource
• source account
• AWS Organization
• VPC or endpoint context
• source IP
• service-specific conditions

The appropriate condition depends on the AWS service and architecture.

Service principals

AWS services frequently appear as principals in legitimate resource policies. For example, a logging or event-delivery service may require permission to write to a resource. A service principal should not automatically be treated as an external attacker.

The investigation should consider:

• which service is trusted
• which action is allowed
• whether source restrictions exist
• whether the trust matches the intended AWS architecture

Public vs cross-account exposure

Securitain distinguishes these concepts so the investigator can focus on the actual trust model.

Supported resource types

The current Securitain Resource Policies view visibly supports filtering for:

• S3
• KMS
• SQS
• SNS

Additional supported resource-policy analysis may evolve over time.

Interpreting risk

A resource-policy risk result should be read together with resource type, principal, action, public or cross-account context, conditions and resource sensitivity. A public read permission and an external administrative capability are not equivalent.

Resource Policies vs Trust Policies

Principal
   ↓
Role Trust
   ↓
IAM Role

Principal
   ↓
Resource Policy
   ↓
AWS Resource

Investigating a risky resource policy

1. 1

   Identify the resource

   Determine service, account, environment, sensitivity and owner.

2. 2

   Identify the principal

   Is it public, another AWS account, another role, an AWS service principal or another supported principal?

3. 3

   Review actions

   Determine whether access is read, write, decrypt, publish/send, administrative or another service-specific capability.

4. 4

   Review conditions

   Understand how the trust is constrained — source account, organization, VPC endpoint or other applicable conditions.

5. 5

   Determine business purpose

   Ask why the access exists. Identify the application, team or AWS service integration that requires it.

6. 6

   Review related identity context

   For external principals, investigate Cross-Account and Effective Permissions.

7. 7

   Remediate carefully

   Reduce unnecessary trust while preserving the legitimate AWS integration.

Evidence and limitations

Resource-policy analysis depends on:

• supported AWS resource types
• resource policy availability
• scan permission
• policy conditions
• resource collection coverage
• scan freshness

Related guides