Cloud Storage Data Inventory Across Multi-Cloud Environments
Knowing where sensitive data lives across clouds is the first step to securing it.
A cloud storage data inventory across multi-cloud environments is the prerequisite for effective data security. Encryption, access controls, and monitoring can protect only the data within their scope. Building that scope requires a continuously maintained map of data stores, owners, identities, and runtime controls, assembled across providers and connected to the engineering work that creates new copies.
Why cloud storage inventory is not a hygiene task but a security prerequisite
A team has encryption, IAM, and a CSPM tool, yet an exposed dataset still comes as a surprise. The missing element is often not another control but an asset that never entered the security map. A snapshot, export, or share can hold sensitive data without appearing in the inventory used to apply those controls. For that data, coverage is absent.
The failure can begin with a store that appears in billing or logs but not in the CMDB. It can persist when an access review counts administrator roles but misses identities that can reach regulated data. Even a posture scanner can identify a problem without producing a fix if the asset has no owner or remediation route. These are failures of scope and responsibility. Discovery must therefore precede classification, protection, access control, drift monitoring, compliance evidence, and recovery testing.
How multi-cloud fragmentation breaks every native inventory tool
That scope is difficult to establish because each provider exposes only part of the estate. AWS CloudTrail, Azure Monitor, and Google Security Command Center do not natively monitor each other’s events. SaaS, Kubernetes, and on-premises systems add further boundaries to the map. Native tools remain useful within those boundaries, but their individual views do not amount to a multi-cloud inventory. The gaps between them obscure where sensitive data lives and which controls apply.
AWS IAM, Azure Active Directory, and Google Cloud IAM have distinct role structures, permission inheritance, and service account models. An overly permissive storage ACL combined with cross-account trust can create an exfiltration path whose significance is not apparent from either setting alone. Encryption also varies through key ownership, rotation rules, decrypt permissions, and exceptions across production stores and copies.
Shadow data: the inventory problem that regenerates itself
Even a complete map becomes stale as ordinary engineering work creates new copies. A developer clones a production database to debug a payment issue, or a platform team restores a backup to validate a schema change. A data team exports a table to a personal GCS bucket to prototype a model. Each task can copy production-grade data without keeping track of who owns it or keeping its retention rules and access controls. Shadow data is therefore a recurring byproduct of delivery.
The same problem extends to AI and LLM workloads through customer tickets in chat tools, sensitive embeddings in vector databases, prompt logs, and over-permissioned connectors. Data can also travel from an application database through Amazon S3, Snowflake, Databricks or BigQuery, and a SaaS support export. Each hop changes the control point, even when the source remains governed. Migrations introduce temporary stores, roles, transfer paths, and snapshots that can survive cutover. An inventory that does not follow these workflows records yesterday’s environment and misses today’s exposure.
What a multi-cloud data inventory actually needs to capture
A useful inventory must answer what a store contains, who owns it, which controls apply, and which controls were verified at runtime. Its scope includes data at rest, in transit, in use, copied, exported, logged, and restored. Owner mapping must cover cloud-native storage, SaaS connectors, exports, and integrations. Classification and environment attributes add the details needed to protect the data in those records. Control records also need the exception, remediation status, and audit trail that explain the current state.
The map of identities must include service accounts, API keys, workload identities, and CI/CD pipeline credentials. The map must answer who has effective permissions over the dataset, including the ability to read, copy, export, decrypt, or share it. Shared accounts, inherited groups, vendor scopes, and old administrator roles can make that answer hard to see. APIs belong in the map because endpoints, microservices, partner integrations, and SaaS connectors can expose or move sensitive data. Billing records, access logs, and SaaS export history can point to stores that the formal inventory may have missed.
How to discover data stores across providers when no single tool sees everything
Discovery requires a combination of sources because each reveals a different blind spot. AWS Config, Azure Resource Graph, and Google Asset Inventory provide the native starting layer, but their results must be aggregated. Multi-cloud CSPM normalization brings policies across AWS, Azure, and GCP into a common view. Billing and cost records then expose resources that exist outside the CMDB. CloudTrail, Azure Monitor, and GCP Audit Logs add access events against assets that may not yet be registered.
Automation is essential because enterprise-scale misconfiguration review is not sustainable as a manual task. Infrastructure-as-code scanning at the PR stage makes creation an inventory checkpoint, avoiding delayed discovery. Just-in-time elevated access with automatic expiry limits the window in which temporary privileges can create forgotten stores. SaaS still needs dedicated enumeration of OAuth token grants, SaaS-to-SaaS integrations, and export paths. Migration sweeps must likewise include staging buckets, temporary roles, and snapshot shares, treating cleanup as a security control.
What breaks when the inventory is incomplete: the Snowflake/UNC5537 campaign
The 2024 Snowflake customer breaches show why an inventory of a data platform must cover the identities that connect to it and the protections on its accounts. UNC5537 used credentials stolen by infostealer malware on customer endpoints to access tenants lacking MFA. The campaign did not exploit a Snowflake platform vulnerability. Attackers identified Snowflake URLs in harvested credential logs, attempted login at scale, and used Snowflake’s own COPY INTO command to export data to attacker-controlled S3 buckets.
Mandiant attributed at least 165 victim notifications to the campaign, including Ticketmaster, AT&T, Santander, Advance Auto Parts, Pure Storage, and Neiman Marcus. A large majority of the accounts leveraged by UNC5537 had prior credential exposure, making the risk visible before it was connected to the tenants needing protection. Identifying a data warehouse without mapping its identities and safeguards leaves the decisive exposure unresolved. This model is replicable across providers wherever compromised credentials, weak account protections, and native export functions meet an incomplete inventory.
How malicious insiders use cloud storage when ACLs are wrong or missing from inventory
Google Cloud’s Threat Horizons Report H1 2026 documents malicious insiders exploiting corporate cloud data whose ACLs were incorrect or too broad. Insiders changed those ACLs to allow over-sharing with personal accounts or external third parties. That access could persist after employment ended. The report says that using corporate cloud services and personally controlled cloud storage is the fastest-growing exfiltration trend and that it expects cloud services to become the main route. It also describes insiders combining cloud transfers with email or USB storage.
Unknown and unowned stores are particularly exposed because ACL changes may have no accountable reviewer. An access review limited to administrator roles can miss an analyst whose standard role reaches a store with excessive write or share permissions. The configuration change on its own may look like normal work. Its meaning changes when considered with the affected data, an unusual access pattern, or proximity to departure. Inventory supplies the store and permission context needed to distinguish routine sharing from preparation for exfiltration.
Why access controls and encryption fail silently on unowned data stores
Without a named owner, no one has clear responsibility to remove excessive access, rotate keys, or respond to drift alerts. A CSPM finding can remain open or be dismissed without the underlying exposure changing. Shared service accounts and inherited permissions make this decay difficult to see through role reviews alone. The control state that matters is what access those identities still have to the data.
A store may remain encrypted while its key-rotation responsibility belongs to a role that no longer exists. Its decrypt permissions may also have passed to a service account from a disbanded team. Across production, backups, replicas, restores, and exports, those differences defeat a simple encrypted-or-not assessment. They also show why a screenshot taken when a store was created cannot prove it is protected now and why compliance evidence increasingly looks at runtime state.
How regulatory requirements have made inventory gaps an audit liability
An unowned store with unverified controls can create exposure under GDPR, HIPAA, PCI DSS, and SOC 2 at the same time. These frameworks may examine the same encryption, access, logging, or retention control while requiring different proof, scope, formats, and review histories. When stores are missing from the inventory, that evidence has gaps before the audit starts. Location adds another dependency because an undiscovered store may sit in a jurisdiction with localization requirements. A transfer cannot be governed completely when a store along its path is unknown.
GDPR enforcement scrutinizes cross-border cloud data transfers, while NIS2 requires evidence of active security monitoring. DORA demands demonstrable cloud resilience testing, and SEC cybersecurity disclosure rules require material incident reporting within tightly defined windows. These obligations make an accurate map relevant to monitoring, recovery, and incident scope as well as access control. Periodic assessment cannot substitute for evidence that controls persisted as the estate changed.
Maintaining inventory over time: making discovery continuous rather than periodic
To last, a program needs to update inventory as part of engineering and security work instead of relying on cleanup campaigns over and over. Infrastructure-as-code pipelines should register new stores and enforce owner assignment and tagging before production deployment. Resources that lack the required owner, classification, and environment tags should be flagged when they are created and blocked from getting certain permissions until they have those tags. Continuous CSPM scanning then tracks posture changes after deployment.
Regular access reviews must cover each store and include service accounts and workload identities as well as people. Employee or contractor departures should trigger a sweep of stores they owned, created, or could access with elevated privileges. Before anyone signs off on a migration or the end of a project, the inventory should be checked and temporary resources cleaned up. Tier 1 data stores holding the organization’s most valuable IP also need configured backups, tested restore paths, and verified control states. Together, these practices make inventory maintenance part of delivery, access governance, offboarding, and recovery.
How behavioral detection on top of inventory closes the gap that static controls cannot
A current inventory establishes what exists and how it is protected, but it cannot alone establish whether permitted activity is appropriate. A routine export for a data engineer can be suspicious when performed by an employee who has just given notice. UNC5537’s use of COPY INTO shows how normal platform functions can be used to steal data. The insider ACL pattern also looks like configuration work when seen on its own. Detection must connect the action to the identity, the data’s significance, its destination, and the person’s wider activity.
That connection also determines how quickly an alert becomes an investigation. A signal that requires hours of manual reconstruction across fragmented logs leaves the essential work unfinished. The investigation view needs to bring the data store, identity, access history, and behavioral context together from the start. Inventory makes the signal intelligible by identifying sensitive data and its owner, while behavioral detection explains why a permitted action may be dangerous.
