Public cloud data security is mis-scoped when the deployment model is treated as a footnote. The same control can have a different owner and evidence trail once the provider operates part of the stack. That changes who can prevent exposure and which log proves the fix.
The Flexera 2026 State of the Cloud report found that enterprise respondents keep 51% of their data in public cloud. Architecture is an operating condition, not a hosting label.
This guide turns three realities into working controls: responsibility that shifts by service, API-driven administration, and policy-defined storage exposure. It then shows how to consolidate inventory and posture evidence without flattening provider object models.
For operational depth, use the cloud data security best practices playbook. Across providers, the remaining job is preserving resource, owner, control, exception, and ticket context in one view.
Key insights
- Public cloud data security has three architectural drivers: the responsibility boundary moves by service, administrative change is API-driven, and isolation is policy-enforced inside multi-tenant infrastructure.
- Treat “private by default” as a starting state, not a control guarantee. A later bucket policy, identity grant, access control list, or organization-policy exception can widen access.
- Amazon S3, Azure Storage, and Google Cloud Storage encrypt data at rest by default. The harder control is key governance: who owns the key, who can use or disable it, how rotation is handled, and which logs preserve evidence.
- Use CIS Foundations Benchmarks as an account-level baseline for identity and access management, logging, monitoring, and networking. They do not replace service-specific hardening or data-level controls.
- Do not force one provider’s object model onto another. Normalize the control intent and the evidence fields: resource, provider scope, owner, environment, sensitivity, exception, finding, ticket, and verification state.
What public cloud data security is?
Public cloud data security is the discipline of protecting data in multi-tenant environments operated by hyperscalers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud, under a shared responsibility model whose boundary changes with the service model and selected service.
Customer responsibility usually narrows from infrastructure as a service (IaaS) through platform as a service (PaaS) to software as a service (SaaS), yet service documentation defines the actual line. The AWS shared responsibility model shows the shift. Amazon EC2 customers manage the guest operating system and application stack. For Amazon S3, AWS operates the infrastructure, operating system, and platform while customers manage data classification, encryption options, and AWS Identity and Access Management (IAM) permissions.
“The cloud provider secures it” is not a control statement. Map responsibilities at service level, not account level. In an illustrative migration from EC2-backed storage to S3, record the data owner, configuration owner, IAM owner, provider-operated layers, and evidence source before retiring the old control set. The dataset may stay the same, but its ownership map does not.
Administrative reach is the second difference. Configuration is API-driven: an authorized Azure Resource Manager REST request can list resources, create a storage account, or delete it. The call goes to management.azure.com even when the storage data plane is private. Authentication and authorization become part of the effective perimeter. Private management paths or network restrictions must be configured where supported; they cannot be assumed.
3 realities that shape public cloud data security
Three architectural realities shape public cloud data security: responsibility moves with the service, administrative change happens through APIs, and storage exposure changes through mutable policy. They determine what the security team must map, restrict, monitor, and prove.
The visual below separates the three control problems before we work through their operational consequences.
1. The shared-responsibility line runs through the middle of your controls
AWS states that customer responsibility changes with the selected service, while Microsoft maps the shift across IaaS, PaaS, and SaaS. Google Cloud’s shared-fate model builds on shared responsibility rather than removing it.
At the IaaS end, Amazon EC2, Azure Virtual Machines, and Compute Engine leave the operating system and workload with the customer. Amazon RDS, Azure SQL Database, and Cloud SQL move operating-system and platform work to the provider. DynamoDB, Azure Cosmos DB, and BigQuery shift the line again, while data classification and customer-configured access remain customer concerns.
Do not copy one generic “cloud” control set across those service classes. For each data-holding service, record the provider-operated layers, customer-operated layers, shared controls, evidence source, control owner, and exception owner. A control without a named side of the responsibility boundary is an assumption, not coverage.
2. The control plane is an API endpoint that is commonly internet-reachable
Reachable does not mean unauthenticated. It means the management surface is no longer bounded by physical access to a data center or by proximity to the workload network. An authenticated Azure Resource Manager REST call, for example, can create or delete a storage account through management.azure.com.
Review the permission path as a transaction: principal, credential, action, resource scope, conditions, session source, and recorded event. If an application’s deployment role can widen a production bucket policy, change replication, or delete an unrelated data store, its authorization scope is wrong.
Apply least privilege, governed attribute conditions, and organization-level denies. The cloud security threats guide covers adjacent credential, API, and account-hijacking paths. Architecturally, require a constrained identity path, a usable audit record, and alerts for new role assumptions, impossible-travel sign-ins, or unusual storage access.
3. Object storage is one misconfiguration away from public exposure unless a higher-level guardrail blocks it
Private by default is only the starting state. Amazon S3 blocks public access for new buckets, access points, and objects by default, and Azure Blob Storage prohibits anonymous access until account and container settings permit it. Google Cloud Storage can grant public access through allUsers, while Public Access Prevention overrides those grants when enforced.
Exposure changes when legitimate sharing mechanisms, inherited IAM, bucket policies, access control lists, or organization-policy exceptions alter effective access. Monitor that state, not merely the creation-time default. Record effective public status, the blocking guardrail, policy source, last change and actor, owner, exception, and evaluation time. Use the CIS Foundations Benchmarks as an account-level baseline, then add service-specific storage checks. Route unexpected drift to the resource owner. A quarterly screenshot proves only what was true that day.
These realities set the control order: map ownership by service, constrain the administrative path, and keep testing effective storage exposure.
The controls that actually matter for data security in public cloud
Public-cloud data controls work as a four-layer stack: governed keys, data-layer authorization, private reachability, and continuous posture evaluation. Apply them in that order. Encryption cannot stop an authorized read; network isolation cannot fix overbroad decryption rights.
Treat encryption as key governance
Amazon S3, Azure Storage, and Google Cloud Storage encrypt data at rest by default. For regulated data, inspect who can create, use, disable, or destroy each customer-managed key and which datasets depend on it. Record the key ID, administrators, workload identities, rotation rule, and audit source in AWS KMS, Azure Key Vault, or Google Cloud KMS. Use BYOK or external key stores only when custody requirements justify the recovery burden.
For single-tenant FIPS 140 Level 3 HSM control, use an AWS CloudHSM key store behind AWS KMS or Azure Key Vault Managed HSM for Azure Storage. Azure Cloud HSM replaces Azure Dedicated HSM for IaaS and PKCS#11 workloads, not Azure PaaS or SaaS integrations.
Enforce access at the data layer
Bucket or resource policies, role-based access control (RBAC) conditions, and attribute-based access control (ABAC) should evaluate each request against the resource. Keep intent stable while provider syntax varies: a Clearance=restricted session may read a DataSensitivity=restricted object; missing sensitivity fails closed.
Test both paths and document services that cannot evaluate the attributes.
Make private reachability a tested state
For Amazon S3, choose a gateway VPC endpoint or AWS PrivateLink interface endpoint based on the source network. Use Azure Private Endpoint for Azure Storage and Private Service Connect for Google APIs. Test DNS from approved and unapproved networks, then restrict public endpoints and egress. This limits where leaked credentials work; it does not narrow access permissions.
Make CIS posture checks continuous
Evaluate the CIS Amazon Web Services Foundations Benchmark, CIS Microsoft Azure Foundations Benchmark, and CIS Google Cloud Platform Foundations Benchmark through cloud security posture management (CSPM), each against its matching account scope. These are account-level baselines, not complete data-service coverage.
Every finding needs the resource, failed rule, owner, exception, first-seen time, ticket, and last evaluation. Close it only after the control passes again. Owner-routed retesting is the operating floor for public cloud data security.
One dashboard across every public cloud where your data lives
Most enterprise estates do not stop at one public cloud. A public cloud data security review may start with Amazon S3, move to Azure Blob Storage, and end in BigQuery. By the third console, the team is translating resource types, ownership fields, and policy results by hand. Running another isolated scan does not fix that translation work.
The review needs one asset cohort with shared application, environment, owner, and compliance-scope fields while native evidence stays visible. Cloudaware carries that model into the next two workflows through normalized CMDB inventory and CSPM evaluations across configured AWS, Azure, GCP, Oracle, and Alibaba connections.
Normalized asset graph across AWS, Azure, GCP, Oracle, and Alibaba
A normalized asset graph earns its name when one PCI query works across AWS, Azure, GCP, Oracle, and Alibaba. If that query still needs five rewrites, the model is provider-shaped. Normalize Application, Environment, Owner, and Compliance Scope. Keep native type, source scope, region, resource ID, and original tags.
Reconciliation is where the model breaks. An Amazon S3 bucket arrives as env=prod; an Azure Blob Storage container uses Environment=Production. Both map to Production. Then the service catalog calls the container Test. The latest value is not a rule, so the CMDB team must define the authoritative source and flag the mismatch.
Once that rule exists, a CMDB administrator can use Cloudaware CMDB to search supported inventory across the five providers with Environment = Production and Compliance Scope = PCI. The result separates records ready for policy evaluation from blank owners and classification conflicts that need repair.
Before trusting the result, compare the native and normalized fields in the same view.
Clean rows prove little. Check the blank Owner, competing Environment values, and provider connection health. Blank or conflicting records are not policy-ready. Unsupported resource types and missing CMDB relationships reduce coverage; an empty result does not prove an empty estate.
Continuous CSPM against CIS Foundations for every cloud
Continuous CSPM reruns the correct provider benchmark after a successful inventory sync and keeps a failed check open until a later evaluation passes. It is not live polling of every cloud API.
Each provider still needs its own policy logic: the CIS Amazon Web Services Foundations Benchmark, CIS Microsoft Azure Foundations Benchmark, and CIS Google Cloud Platform Foundations Benchmark. CIS describes these benchmarks as account-level starting points. A green scorecard cannot prove that every storage or database control is secure.
An illustrative review contains one failed rule per provider. A rule ID names the gap but cannot route it; the compliance manager still needs application, environment, owner, exception, SLA, and ticket state.
Once the CMDB records carry those fields, Cloudaware CSPM runs scheduled policy evaluations and exposes findings with owner and SLA context. Custom controls use a YAML-based language, with policy files reviewed in Git. Configured Jira or ServiceNow integrations carry findings into the work queue. Compare the result, ticket state, and last evaluation below.
Cloudaware CSPM dashboard. The provider-specific CIS findings share one workflow for ownership, exceptions, tickets, and reevaluation.
Start with Ticket status = Resolved and Policy result = Failed. Rerun after the next successful sync; keep the finding open unless it passes. A closed ticket is not proof of a passing control. Failed syncs and unsupported objects remain outside the denominator.