Trust Gaps: Security Risks and Foundations of Cloud Computing

Introduction

Cloud computing is a model for enabling on-demand network access to a shared pool of configurable computing resources — including servers, storage, applications, and services — that can be rapidly provisioned and released with minimal management effort, a definition formalized by the National Institute of Standards and Technology (NIST) in its Special Publication 800-145 (2011). The early theoretical foundations of this model, including its core security tensions, were analyzed in the landmark IEEE 2010 survey by Subashini and Kavitha, "A Survey on Security Issues in Service Delivery Models of Cloud Computing," which established that the cloud's architectural advantages — elasticity, multi-tenancy, remote access — are precisely the properties that create its most persistent vulnerabilities. This paper argues that the security challenges documented by Subashini and Kavitha are not incidental engineering problems awaiting a technical patch, but are structurally embedded in the foundational design of cloud computing itself: the outsourcing of control is inseparable from the outsourcing of risk, and no layering of best practices fully resolves that fundamental tension.

The Architecture of Shared Risk

The foundational premise of cloud computing — that resources are pooled and shared across multiple tenants — creates an attack surface that has no direct analog in traditional dedicated-server environments. Subashini and Kavitha identify the three primary service delivery models (Software as a Service, Platform as a Service, and Infrastructure as a Service) as each carrying a distinct security profile, but all three share the core liability of multi-tenancy: multiple customers occupy the same physical hardware, managed through virtualization layers that can themselves become vectors of attack. This is not a marginal concern. The authors demonstrate that virtualization introduces hypervisor vulnerabilities that, if exploited, allow one tenant's workload to observe or corrupt another's — a class of attack sometimes called a "VM escape." The 2009 discovery of vulnerabilities in VMware's hypervisor products, widely reported in security literature, offered an early concrete illustration of precisely this risk materializing in production environments.

As Kaufman argues in her 2009 IEEE Security and Privacy article on data security in the cloud, the loss of physical control over hardware is not merely an operational inconvenience but a fundamental reordering of the trust relationship between customer and provider. In traditional IT, a firm's security team can audit physical access logs, inspect hardware, and enforce perimeter controls. In the cloud, those controls are delegated entirely to the provider, whose internal practices may be opaque. This opacity constitutes the primary security risk, outweighing even the technical vulnerabilities of any specific protocol or implementation. The implication is significant: improving encryption or patching hypervisors addresses symptoms, while the underlying cause — the structural dependency on a third party's undisclosed security posture — persists unchanged. Subashini and Kavitha reinforce this point by cataloguing the ways in which even well-intentioned providers create risk through inadequate isolation between service tiers, demonstrating that the problem is architectural rather than behavioral.

Data Protection and the Problem of Jurisdiction

Among the specific vulnerability categories that Subashini and Kavitha enumerate, data security challenges are both the most immediately consequential and the most legally complex. Cloud data does not sit in one location. It is replicated across geographically distributed data centers, often spanning multiple national jurisdictions, and this geographic dispersion creates a fundamental tension with data protection law. The authors note that a customer storing personal data in a cloud environment may find that data physically resident in a country whose legal framework permits government access without the procedural protections of the customer's home jurisdiction. This is not a hypothetical scenario. The USA PATRIOT Act, enacted in 2001 and extended in modified form as the USA FREEDOM Act in 2015, grants U.S. authorities broad subpoena power over data held by U.S.-headquartered companies regardless of where that data is physically stored — a provision that directly conflicts with the data sovereignty requirements of the European Union's General Data Protection Regulation (GDPR), which came into force in 2018.

Mowbray, writing in 2009 on the fog of cloud privacy, examines exactly this jurisdictional collision and concludes that standard contractual clauses — the legal instrument most commonly used to authorize cross-border data transfers — offer only procedural rather than substantive protection. A contract clause cannot override a foreign government's lawful access demand; it can only determine who bears the liability after the fact. Subashini and Kavitha's treatment of data integrity and confidentiality in the cloud aligns with Mowbray's diagnosis: encryption of data at rest and in transit, while necessary, does not resolve the jurisdictional exposure, because encryption keys must ultimately reside somewhere, and if that somewhere is within the cloud provider's control, a lawful government demand for keys extinguishes the protection. The argument here is not that cloud storage is uniquely unsafe compared to alternatives, but that the security risks are qualitatively different in ways that neither customers nor regulators initially appreciated. The Schrems II ruling by the Court of Justice of the European Union in July 2020, which invalidated the EU-U.S. Privacy Shield framework, confirmed that these jurisdictional tensions are unresolved at the highest levels of international law.

Foundational Vulnerabilities in Service Delivery Models

Subashini and Kavitha's most analytically useful contribution is their systematic mapping of security vulnerabilities onto the three service delivery models, demonstrating that each model distributes the security responsibility boundary differently and therefore creates a distinct risk profile. In the SaaS model, the customer controls almost nothing: the provider manages infrastructure, platform, and application, leaving the customer responsible only for user credentials and access management. This means that a vulnerability in the provider's application code — a SQL injection flaw, a broken authentication mechanism, an inadequate session management routine — is entirely outside the customer's ability to detect or remediate. The 2012 LinkedIn data breach, in which approximately 6.5 million user password hashes were exposed due to inadequate hashing (the company used unsalted SHA-1 rather than a memory-hard function), illustrates how application-layer failures at a major SaaS-adjacent provider can affect millions of users who had no visibility into the underlying security implementation.

The PaaS model distributes responsibility differently: the provider secures infrastructure and platform runtime, while the customer is responsible for the application code deployed on that platform. As Armbrust and colleagues argue in their 2010 Communications of the ACM article "A View of Cloud Computing," this division of responsibility creates what they describe as a "accountability gap," where neither party has full visibility into the combined system's security posture. A customer's application may be impeccably coded, but if the platform runtime contains a vulnerability, the application inherits that risk. Conversely, the provider's secure runtime can be undermined by insecure customer code, and the provider may have limited contractual liability for consequences that originate in customer deployments. Subashini and Kavitha document this gap precisely, noting that in the PaaS context, the customer is dependent on the provider's platform APIs — and those APIs represent an additional attack surface whose security properties are often inadequately documented. The IaaS model, in which the customer controls the virtual machine and everything above it while the provider manages physical infrastructure and the hypervisor, shifts the most responsibility to the customer but does not eliminate provider-originated risk, because hypervisor vulnerabilities remain entirely within the provider's control to address or ignore.

Jensen and colleagues, in their 2009 analysis of cloud computing security threats presented at the IEEE International Conference on Web Services, introduce the concept of the "XML signature wrapping attack" as a concrete illustration of how IaaS APIs — specifically SOAP-based management interfaces — can be exploited to allow unauthorized control of virtual machine instances. This attack class targets the authentication and authorization layer of cloud management APIs and demonstrates that the foundational protocols on which cloud infrastructure is built were not designed with the adversarial multi-tenant environment of public cloud computing in mind. Subashini and Kavitha cite this category of vulnerability as evidence that the cloud security problem is not simply a matter of applying existing security best practices to a new environment, but of recognizing that the environment itself requires new security primitives.

Conclusion

The significance of Subashini and Kavitha's 2010 IEEE survey extends beyond its enumeration of specific vulnerability classes. Read carefully, it reveals that the cloud's security challenges are not engineering problems awaiting sufficiently clever solutions but are tensions inherent in the foundational architecture of shared, remotely managed, multi-tenant computing. The outsourcing of infrastructure is simultaneously the outsourcing of a portion of security control, and that portion cannot be fully reclaimed through contractual due diligence, encryption, or access management frameworks — all of which are necessary and none of which is sufficient.

The subsequent decade of cloud security history, from the Jensen team's documentation of API-level attack classes to the Schrems II ruling's confirmation of irresolvable jurisdictional tensions to the Capital One breach's illustration of the accountability gap in practice, has not refuted Subashini and Kavitha's framework. It has extended and confirmed it. What has changed is the scale of cloud adoption, which means the structural risks they identified in 2010 now apply to an immeasurably larger fraction of the world's sensitive data. The most productive response to this situation is not to retreat from cloud adoption — the counterargument correctly identifies the genuine security gains that cloud infrastructure provides — but to approach cloud security with clear-eyed recognition that the trust gap is permanent, that best practices manage rather than eliminate it, and that regulatory frameworks, contractual structures, and technical controls must be designed with that permanence in mind. The cloud's foundational promise of shared resources and delegated management is also its foundational security challenge, and the two cannot be separated.