Protecting sensitive data in AWS requires layered access and encryption

At a glance

What this is: Sentra argues that AWS data protection fails when sensitive data is handled as a storage problem instead of a layered lifecycle problem spanning IAM, encryption, discovery and log masking.

Why it matters: IAM, PAM and cloud security teams need a single control model because broad roles, exposed logs and weak encryption each expand the blast radius for both human and non-human access paths.

Context

Protecting sensitive data in AWS is not just an encryption task. The real governance gap appears when teams split storage controls, identity controls and logging controls into separate workstreams, leaving each one blind to the others.

AWS environments create exposure through several paths at once, including over-permissive roles, public or misconfigured buckets, database access outside private boundaries and logs that capture PII. For identity and access teams, the key issue is that the same data can be reachable through direct storage access, application roles and operational telemetry.

Key questions

Q: What breaks when AWS data security controls are managed separately from IAM?

A: The main failure is that permissions can expand the real attack surface faster than data owners realise. When IAM, secrets, and storage controls are governed in isolation, a role may expose more data than intended and a misconfiguration can remain invisible until access is already broad. Organisations need one view of effective access, not separate views of policy and data.

Q: Why do over-permissive AWS roles increase sensitive data risk?

A: Because a role that can read, decrypt, export, or inspect data can bypass storage protections even when encryption is enabled. In cloud environments, identity scope determines how far a compromised service or workload can move. Excess privilege increases blast radius and makes data controls easier to route around.

Q: What are the signs that CloudWatch log masking is failing?

A: Common signs include sensitive fields appearing in older log groups, unmasked records visible to broad audiences, and protection policies added after logs already contain regulated data. If logs remain readable before masking is applied, the control is too late to prevent exposure. Audit both policy timing and who can use logs:Unmask.

Q: How should teams govern AWS access when sensitive data is spread across multiple accounts?

A: Teams should correlate IAM entitlements with data classification so they can see who can reach each sensitive datastore and at what privilege level. A role-only review is not enough because cross-account trust, inherited permissions, and federated identities can hide real exposure. The practical outcome is a permissions matrix that supports remediation, recertification, and audit evidence.

Technical breakdown

Layered encryption for AWS data at rest and in transit

Encryption in AWS only reduces exposure when it is applied at the right layer and tied to access policy. Field-level encryption protects the most sensitive values before they reach storage, while encryption at rest on S3, EBS and RDS limits exposure if the underlying service is accessed improperly. Customer-managed keys in KMS add governance over rotation and access, but they do not replace identity control. TLS protects data in motion, and private subnets with security groups and VPC endpoints reduce unnecessary network paths. The architectural point is that encryption should narrow where plaintext exists, not be treated as a single control that solves all exposure paths.

Practical implication: Use encryption by layer and by data class, not as a blanket checkbox.

Why IAM least privilege is still the decisive control in AWS

Sensitive data protection in AWS fails quickly when IAM roles can reach more data than their function requires. Least privilege matters because storage encryption does not stop a role with valid access from reading decrypted data, and public or cross-account misconfigurations often begin with overly broad permissions. AWS IAM Access Analyzer helps surface policy reachability that teams may not notice manually, but the deeper issue is entitlement sprawl across service roles and operational accounts. In practice, identity governance determines whether encrypted data remains meaningfully restricted or simply becomes encrypted data that too many principals can still access.

Practical implication: Review AWS IAM policies for data reachability, not just login activity.

CloudWatch log masking and data protection policies

Logging becomes a data exposure channel when request payloads, error traces and debug output contain identifiers, tokens or regulated fields. CloudWatch Logs data protection policies apply detection and masking as events are ingested, which is stronger than retroactive cleanup because the sensitive value may already have been stored, searched or replicated. But the control only works if policies exist at log group creation, and unmask permissions are tightly limited. This is a governance problem as much as a technical one: observability pipelines must be treated as data handling systems, not merely operational telemetry.

Practical implication: Apply masking at log ingestion and restrict unmask access to a very small group.

Threat narrative

Attacker objective: The objective is to reach sensitive data through whichever AWS layer offers the weakest control, then use that access to exfiltrate or misuse it.

1. Entry occurs when sensitive data is written into misconfigured buckets, over-permissive IAM paths or logs that capture PII without masking.
2. Credential or access abuse follows when principals with excessive rights can reach decrypted content or unprotected telemetry.
3. Impact is exposure, exfiltration or unauthorized reuse of sensitive data across storage, application and logging layers.

Breaches seen in the wild

• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Layered data governance is now the only credible AWS protection model: encryption, IAM and logging are interdependent controls, not separate domains. If any one layer is treated as sufficient on its own, the others become the path of least resistance. For practitioners, the implication is simple: govern data reachability end to end, not service by service.

AWS data exposure is often an identity problem before it is a storage problem: misconfigured buckets matter, but over-permissive roles decide whether those buckets are actually reachable. That makes entitlement review, service-role scoping and access-analyzer-style validation central to data protection. Teams that focus on storage posture while ignoring permission reachability are managing symptoms, not exposure.

CloudWatch masking turns observability into a security control only when lifecycle governance is in place: log protection must begin at creation, and unmask rights must be exceptional. This is a strong example of where human IAM and non-human access meet, because application roles, automation and analysts all interact with the same telemetry. Practitioner conclusion: treat logs as regulated data assets, not disposable operational output.

Field-level encryption is the right answer when the business still needs plaintext for non-sensitive data: it preserves utility while shrinking the plaintext footprint. That matters in AWS because many organisations over-encrypt broadly, then create operational exceptions that weaken the whole model. The sharper concept here is plaintext minimisation: only the necessary fields should ever exist unencrypted, and only for the shortest defensible path.

Shadow data becomes shadow risk when teams cannot see where sensitive fields move across services: point-in-time service controls do not reveal how data propagates between accounts, regions and logs. The governance issue is visibility into data movement, not just storage location. Practitioners should assume that any untracked copy, export or debug stream is part of the attack surface until proven otherwise.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: NHI Lifecycle Management Guide

What this signals

Plaintext minimisation: the most durable AWS data protection strategy is to shrink where sensitive data exists in clear form, then make every remaining access path intentional. That changes the governance question from "is it encrypted?" to "where can plaintext still emerge?"

Identity teams should treat AWS data protection as a permissioning problem with encryption attached, not the other way around. When service roles, analysts and automation all touch the same datasets, access scope becomes the control that determines whether encryption is meaningful or symbolic.

CloudWatch masking, Macie-style discovery and KMS-backed encryption are strongest when they operate as one operating model. The reader takeaway is to align discovery, masking and entitlement review so data movement does not outrun the control estate.

For practitioners

• Implement field-level encryption for high-risk data Encrypt only the sensitive fields that require protection, such as identifiers and payment data, so application utility is preserved while plaintext exposure is reduced.
• Tighten IAM around data-reachability paths Review IAM roles for access to S3, RDS and supporting services, then remove permissions that are broader than the task the role actually performs.
• Enforce encryption by default on storage services Require encryption on S3 buckets, EBS volumes and RDS databases, and use customer-managed keys where rotation and access policy need stronger governance.
• Apply log masking at creation time Create CloudWatch data protection policies when log groups are created, limit logs:Unmask to a small set of approved users, and route findings into audit trails.
• Centralise discovery across accounts and regions Track where sensitive data moves across AWS services so shadow copies, redundant stores and obsolete data can be governed before they expand the blast radius.

Key takeaways

• AWS sensitive data risk is driven by the combination of broad IAM roles, weak encryption boundaries and logs that capture regulated content.
• The most common failure is treating storage, identity and observability as separate controls instead of one governed data lifecycle.
• Teams reduce blast radius by combining field-level encryption, least privilege, early log masking and continuous discovery across AWS services.

Key terms

• Field-Level Encryption: Field-level encryption protects selected sensitive values inside a record rather than encrypting the entire object or database uniformly. It is useful when only part of a payload needs strong protection, but it still depends on tightly controlled keys, access policies, and downstream handling of decrypted data.
• Customer Managed Key: A key that an organisation creates and controls rather than using the cloud provider's default managed key. It gives the organisation more policy, audit, and custody control, but it also shifts responsibility for grants, rotation, and lifecycle governance onto the team that owns it.
• Log Data Protection Policy: A log data protection policy detects or masks sensitive information as logs are ingested. It helps turn observability into a controlled data flow, but it only works as intended when the policy exists before sensitive events are written and when unmask permissions are tightly limited.
• Plaintext Minimisation: Plaintext minimisation is the practice of reducing how much sensitive data exists in unencrypted form and for how long. It is a governance pattern rather than a single tool, and it is especially valuable in cloud environments where data can move quickly across services, logs and automation paths.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader data and access decisions that shape cloud exposure.