Cloud data security gaps are driven by misconfigurations and identity risk

At a glance

What this is: This is an Orca Security analysis of cloud data security, arguing that misconfigurations and identity-driven exposure are the main reasons cloud data is leaked or breached.

Why it matters: It matters because IAM, NHI governance, and human access controls all shape whether cloud data stays protected as environments scale, change, and sprawl.

By the numbers:

• The 2024 Verizon DBIR identified misconfiguration as a contributing factor in 15% of all cloud breach incidents analyzed.

👉 Read Orca Security's analysis of cloud data security controls and exposure risks

Context

Cloud data security is the discipline of protecting data at rest, in transit, and in use across cloud services through encryption, access control, monitoring, and lifecycle governance. In practice, the biggest failures come from exposure paths that are easy to miss: public buckets, shared snapshots, overbroad service account permissions, and data copied into places the security team never inventoried.

The identity connection is central. Cloud data exposure is rarely just a storage problem; it is often a consequence of IAM policy design, NHI sprawl, and weak visibility into who or what can read sensitive data. That makes cloud data security a cross-programme issue for IAM, NHI governance, DSPM, and incident response teams, not a single tool category.

Key questions

Q: How should security teams reduce cloud data exposure from misconfigured storage?

A: Start with continuous configuration monitoring on storage, snapshots, and backup locations, then block public access and unsafe sharing by default. The key is to compare live state against an approved baseline and treat any drift as exposure until proven otherwise. Visibility without enforcement only tells you where the breach will happen.

Q: Why do non-human identities increase cloud data risk?

A: Non-human identities often have broad, persistent access to storage and analytics services, which makes them easy to overlook in human-focused access reviews. If a service account can read many datasets, compromise or misuse of that identity can expose far more data than the original task required. Lifecycle review for these identities is essential.

Q: What do teams get wrong about cloud data security monitoring?

A: They often collect logs without correlating identity, object access, and data movement. That leaves them able to see activity, but not to determine whether a sensitive dataset was actually reached or moved out of scope. Monitoring must join telemetry to the data inventory, or the alerting remains incomplete.

Q: Who is accountable when cloud data is exposed through a shared account or snapshot?

A: Accountability sits with the organisation operating the cloud resource, even when the provider supplies the platform. Teams that own the data, the identity policy, and the logging settings must prove why exposure was possible and what prevented earlier detection. Shared responsibility does not mean shared ambiguity.

Technical breakdown

Why cloud storage misconfigurations expose data so quickly

Cloud storage services are designed for speed and scale, which means defaults can be permissive and changes can propagate faster than manual review. Public S3 buckets, shared database snapshots, and overly broad object permissions create direct paths to sensitive data when access controls are not continuously evaluated. The real failure mode is not complexity alone, but state drift: a resource that was private at creation can become exposed through a later policy change, copy operation, or cross-account share. CSPM is useful here because it checks configuration state against expected baseline, but only if teams define the baseline correctly and keep it aligned to business intent.

Practical implication: continuously evaluate cloud resource exposure against approved baselines, with alerts on public access, shared snapshots, and cross-account sharing.

How identity permissions widen the cloud data attack surface

Cloud data exposure is often enabled by identities that can read far more than they need. Service accounts, instance profiles, and workload roles commonly outnumber human users, and many are created for a temporary task but never reduced or removed. That creates standing read paths into storage, analytics, and backup systems. The problem is structural: access was provisioned for operations, but it persists into normal production life. In an identity-heavy cloud, the question is not whether data is encrypted, but whether any identity can still reach it without a business need.

Practical implication: review non-human permissions separately from human access and remove broad read scopes from service and workload identities.

Why visibility gaps turn exposure into a long-lived breach

Cloud logging can expose access to sensitive data, but many of the needed logs are not enabled by default. Without object-level storage logs, identity activity logs, and movement tracking, teams cannot easily see where sensitive data lives, who touched it, or whether it left expected boundaries. That is why breaches in cloud environments often persist for months. DSPM fills part of the gap by discovering sensitive data, while SIEM and cloud-native telemetry help explain access patterns. The architecture challenge is correlation: data location, identity, and movement must be analysed together rather than as separate signals.

Practical implication: enable storage access logging, identity audit logs, and data movement telemetry together so exposure can be detected and investigated.

Threat narrative

Attacker objective: The attacker objective is to reach and remove sensitive cloud data before the organisation notices the exposure path or revokes access.

1. Entry occurs through an exposed cloud storage path such as a public bucket, a shared snapshot, or a compromised IAM credential that can already read sensitive data.
2. Escalation happens when broad service account permissions or missing monitoring let the attacker or insider move from one dataset to additional cloud assets without friction.
3. Impact is sustained data exposure, exfiltration, or unauthorized access that remains undiscovered because the organisation lacked complete inventory and access visibility.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud data security is an identity problem before it is a storage problem. The article's own examples show that exposure usually begins when an identity can read too much, not when encryption fails. That means cloud data governance has to treat IAM, NHI lifecycle, and storage configuration as one control plane. Practitioners should judge cloud security by whether access paths are still explainable, not just whether data is encrypted.

Expanded attack surface: more identities, more copies, less certainty. Cloud environments multiply the number of service accounts, workload roles, snapshots, and replicas that can reach the same data. The consequence is not only more exposure points, but more ambiguity about which identity owns which dataset at any moment. That ambiguity is what makes containment slow. Practitioners need to assume every extra access path is a new governance obligation.

Shadow data creates hidden compliance debt as well as breach risk. The article makes clear that teams cannot protect what they have not inventoried, and cloud storage makes untracked data easy to create. This is where DSPM becomes a governance control rather than a discovery feature. Practitioners should treat unknown data locations as unresolved risk, not as an operational nuisance.

Standing access on service identities is the quiet failure mode here. Cloud data security programs often focus on human users, but the article points to service accounts and machine identities as a major part of the attack surface. That is exactly where least privilege erodes over time: access granted for a task becomes durable access to data. Practitioners should re-evaluate how non-human identity entitlements are reviewed, approved, and retired.

Continuous monitoring only works when access, data, and movement are joined up. Separate dashboards for storage, IAM, and logging do not answer the real question of whether sensitive data is actually reachable. The operational gap is correlation, not telemetry volume. Practitioners should build detection around the path from identity to object to destination.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• That same research also shows that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which is why the 52 NHI breaches Report remains a useful next reference point.

What this signals

Shadow cloud data is likely to remain a recurring control failure until teams treat inventory as a security function, not a documentation task. Once data can be created in multiple cloud services without a central owner, the old model of periodic review stops being enough. Organisations need continuous discovery tied to access state, otherwise the first reliable signal arrives after exposure has already occurred.

Ephemeral infrastructure does not reduce governance pressure, it shifts it to identity and telemetry. The cloud expands and contracts faster than manual review can follow, so the durable control points are IAM policy, logging, and data classification. Teams that still anchor their programme on asset lists alone will miss the path from identity to data movement.

With more than 1 in 5 non-human identities believed to be insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities, cloud data security programmes should assume machine access is already part of the exposure profile and govern accordingly. That means separate review cadences for workload identities, tighter entitlement boundaries, and better correlation between storage events and identity state.

For practitioners

• Inventory sensitive data across cloud services Scan storage, backup, warehouse, and analytics services for regulated or high-value data, then maintain a living map of where each dataset resides and which identities can reach it.
• Separate human and non-human access reviews Review service accounts, instance profiles, and workload roles on their own schedule so broad read permissions do not hide inside human-centric access recertification cycles.
• Turn on object-level cloud telemetry Enable CloudTrail data events, Blob access logs, and equivalent object-level logging so you can trace reads, writes, and cross-account access against sensitive datasets.
• Map cloud controls to compliance evidence Tie encryption, access control, and logging settings to the controls required by HIPAA, PCI DSS v4.0, GDPR, and SOC 2 so audit evidence is produced continuously instead of at renewal time.

Key takeaways

• Cloud data breaches usually begin with reachability problems, not encryption failures, which makes IAM and storage configuration inseparable controls.
• Identity sprawl, missing telemetry, and untracked data locations combine to create long-lived exposure windows that standard monitoring often misses.
• Practitioners should govern cloud data as a living access problem by aligning discovery, logging, entitlement reviews, and compliance evidence generation.

Key terms

• Cloud Data Security: Cloud data security is the discipline of protecting data stored, processed, and transmitted across cloud services. It combines encryption, access control, monitoring, and governance so sensitive data remains confidential, intact, and available even as infrastructure and identities change constantly.
• Data Security Posture Management: Data Security Posture Management is the continuous discovery and classification of sensitive data across cloud environments, paired with assessment of whether that data is exposed or protected. It helps teams find shadow data, identify risky configurations, and connect data location to access state.
• Non-Human Identity: A non-human identity is any machine- or workload-based identity used to access systems, services, or data. That includes service accounts, API keys, tokens, certificates, and workload roles, all of which require lifecycle governance because they can persist far beyond the task that created them.
• Cloud Security Posture Management: Cloud Security Posture Management is the continuous evaluation of cloud configuration against a security baseline. It is used to detect misconfigurations such as public storage, unsafe sharing, and drift from approved settings before those changes become data exposure incidents.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: cloud data security controls and exposure risks. Read the original.