Identity-to-Data Intelligence

Understand which AWS identities can reach supported sensitive data resources.

Traditional IAM analysis often starts from the principal: what permissions does this user or role have? Data-security teams often need the inverse question: who can reach this resource?

Securitain connects supported identity and data-security context so teams can investigate access from both directions.

Where to find sensitive access

The current product view is named Sensitive Data Access. The view is designed to help answer: who can read, decrypt or otherwise access supported sensitive data resources across the selected AWS account scope?

Identity-to-data relationship

A simplified data-access relationship involves an identity, a permission and an AWS data resource. But real data access can involve more than one security layer.

Identity
   ↓
Data Read Permission
   ↓
Data Resource

Identity
   ↓
Data Read Permission
   ↓
Encrypted Resource
   +
KMS Decrypt Permission
   ↓
Readable Data

Resource policies can also contribute to the access path. This is why identity-to-data analysis connects naturally with Effective Permissions, Resource Policies, Toxic Permission Combinations and KMS security.

What Sensitive Access can show

Depending on available evidence, the current product can represent context such as:

• principal ARN and principal type
• action
• resource ARN and resource service
• access type
• severity
• access source or relationship, where available
• last-seen evidence, where available

Current filters include service, principal type, action, severity and search across principals, resources and actions.

Start from an identity

Use identity-first analysis when investigating a specific principal.

DataProcessorRole
      ↓
s3:GetObject
      ↓
Sensitive S3 Resource

Then ask:

• What resource is involved?
• Is KMS also required for full access?
• Is access same-account or cross-account?
• Which access relationship contributes?
• Is this access expected?

Start from a resource

Use resource-first analysis when protecting a sensitive workload.

Sensitive S3 Bucket
      ↑
Role A
Role B
External Principal

This is especially useful for regulated data, production data stores, encryption keys and shared datasets.

Read access vs decrypt access

Data access is not always a single action. An identity may have permission to retrieve encrypted data but not decrypt it — or decrypt capability without permission to retrieve the underlying object.

s3:GetObject
without
kms:Decrypt

s3:GetObject
+
kms:Decrypt

Use Toxic Permission Combinations for the permission-combination perspective.

Resource policies

A resource can grant access directly through a supported resource policy. Identity-to-data review should not look only at the principal's attached IAM policies — the resource itself may grant access to external or cross-account principals.

Use Resource Policies to investigate direct resource-side trust.

KMS and encryption context

KMS is frequently part of sensitive-data reachability. A complete investigation may require understanding the data-resource permission, KMS key access, key policy, IAM permission and resource scope together.

Severity

Sensitive-access severity can help prioritize review. Interpret severity together with:

• principal privilege
• action
• resource sensitivity
• encryption context
• same-account vs external relationship
• last-seen evidence

A single severity value should not replace the underlying evidence.

Last-seen context

Where available, a last-seen timestamp can help show whether the access relationship has recent activity evidence. Use the timestamp as supporting context — not as proof that access is safe, not as proof that an older relationship is permanently unused.

Identity-to-Data vs Resource Policies

Identity-to-Data vs Least Privilege

A permission can be actively used and still create excessive data exposure. Therefore data reachability and least privilege should be reviewed together.

Identity-to-Data vs Blast Radius

Blast radius is broader — it considers potential consequence across supported privileged capabilities. Identity-to-Data focuses specifically on the relationship between principals and sensitive data resources.

Investigating sensitive access

1. 1

   Identify the principal

   Determine user or role, workload, owner and account.

2. 2

   Identify the action

   Examples include read, decrypt, write and other service-specific data actions.

3. 3

   Identify the resource

   Determine service, ARN, account, environment and sensitivity.

4. 4

   Review how access is established

   Where available, inspect whether access is associated with an identity policy, resource policy, KMS-related relationship or another supported source.

5. 5

   Review related controls

   Check resource policy, KMS, cross-account context and public exposure.

6. 6

   Review activity context

   Use last-seen evidence where available.

7. 7

   Decide whether access is expected

   Map the relationship to a real application or team purpose.

8. 8

   Reduce unnecessary reachability

   Use least privilege or resource-policy remediation where appropriate.

Evidence and limitations

Identity-to-Data Intelligence depends on:

• supported data-resource collection
• IAM and effective-permission context
• resource-policy coverage
• encryption and KMS context
• access-source evidence
• account scope
• scan freshness

Related guides