# What Is Cloud Computing and Its Security Implications
Cloud computing fundamentally changed how organizations build, deploy, and operate information systems. Rather than purchasing and maintaining physical hardware, organizations now rent compute, storage, and software capabilities from providers who operate massive shared infrastructure. This shift solved real problems: capital expense reduction, faster deployment, and elastic scaling. But it also introduced a new class of security challenges that did not exist when every server sat in a corporate data center. Understanding cloud computing is not optional for security practitioners. Every modern environment includes cloud services, and every modern attacker knows how to exploit misconfigured cloud resources.
---
Cloud computing is the delivery of computing services, including servers, storage, databases, networking, software, analytics, and intelligence, over the internet. The National Institute of Standards and Technology (NIST) defines it in Special Publication 800-145 as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.
The three primary service models define where provider responsibility ends and customer responsibility begins:
Infrastructure as a Service (IaaS) provides virtualized compute, storage, and networking. The customer manages the operating system and everything above it. Examples include Amazon EC2, Microsoft Azure Virtual Machines, and Google Compute Engine.
Platform as a Service (PaaS) provides a managed runtime environment. The provider handles the operating system and middleware; the customer manages applications and data. Examples include AWS Elastic Beanstalk, Google App Engine, and Azure App Service.
Software as a Service (SaaS) delivers fully managed applications over the internet. The provider manages everything from infrastructure to the application layer; the customer configures and uses the software. Examples include Microsoft 365, Salesforce, and Google Workspace.
Cloud computing is NOT the same as outsourcing, managed hosting, or virtualization alone. A virtual machine running on a server in your own data center is virtualization, not cloud. Cloud requires on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service, as defined by NIST.
Deployment models add further scope: public cloud (shared infrastructure operated by a provider), private cloud (dedicated infrastructure operated by or for a single organization), hybrid cloud (combination of both), and multi-cloud (use of services from multiple public cloud providers simultaneously).
---
Understanding cloud security requires understanding the underlying mechanics of how cloud services operate, because the security implications follow directly from the architecture.
Shared Responsibility Model
Every cloud provider publishes a shared responsibility model that defines which security controls the provider handles and which the customer must implement. In IaaS, the provider secures the physical data center, hypervisor, and network fabric. The customer secures the operating system, applications, identity configuration, data, and network controls like security groups. In SaaS, the provider handles nearly everything, but the customer still owns identity management, data classification, and access configuration.
The critical operational reality is that most cloud security incidents do not result from provider failures. They result from customer misconfiguration of resources the customer was responsible for securing. A storage bucket set to public, an administrative account without multi-factor authentication, or an overly permissive IAM role are all customer-controlled. Attackers know this.
Identity and Access Management in the Cloud
Cloud platforms replace traditional network perimeter controls with identity as the primary security boundary. Every action in a cloud environment, creating a virtual machine, reading a storage object, invoking a function, is authorized through an identity and access management (IAM) system. Misconfigured IAM policies are the most common root cause of cloud breaches.
A concrete example: a developer creates an EC2 instance and attaches an IAM role with AdministratorAccess because it is convenient during testing. That instance later runs a web application with a server-side request forgery (SSRF) vulnerability. An attacker exploits the SSRF to query the instance metadata service, retrieves the temporary credentials associated with the overly permissive role, and uses those credentials to exfiltrate data from S3 buckets and pivot to other services. The attacker never touched the operating system or exploited any software vulnerability beyond the SSRF. The breach was entirely an IAM problem.
Network Security in Cloud Environments
Traditional network security relied on physical segmentation and perimeter firewalls. Cloud networking virtualizes all of this. Security groups, network access control lists (NACLs), virtual private clouds (VPCs), and private endpoints replace physical firewalls and switches. These controls work, but they require deliberate configuration.
A common misconfiguration is an administrative port (SSH on port 22 or RDP on port 3389) exposed to 0.0.0.0/0, meaning the entire internet. Automated scanners operated by attackers and security researchers find these exposures within minutes of provisioning. The CIS Benchmarks for cloud platforms specifically address this class of misconfiguration with prescriptive guidance.
Data Security and Encryption
Cloud storage services support encryption at rest and in transit, but customers must configure them correctly. Server-side encryption is often available by default, but key management matters. Customer-managed keys (CMK) through services like AWS KMS or Azure Key Vault give organizations control over encryption keys, which is essential for regulated workloads. Encryption in transit requires enforcing TLS and disabling legacy protocol support.
Data residency is a related concern. Cloud providers operate regions in multiple countries, and data stored in a particular region stays there unless explicitly replicated. Organizations with GDPR, HIPAA, or other regulatory obligations must configure storage and processing to match required jurisdictions.
Logging and Visibility
Cloud environments generate extensive audit logs through services like AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs. These logs record every API call, including who made it, from where, at what time, and what resource was affected. This telemetry is invaluable for detection and response, but only if it is enabled, centralized, and monitored. A significant number of organizations run cloud environments with audit logging disabled or with logs stored in the same account they are meant to protect, which allows an attacker with sufficient access to delete their own trail.
A Specific Scenario
A financial services firm migrates a customer database to a managed cloud database service (PaaS). The migration team enables public accessibility for convenience during the migration and forgets to disable it afterward. No encryption is enforced on the connection string. The database does not require SSL. Three weeks later, automated scanners identify the publicly accessible database endpoint. The attackers authenticate using credentials found in a public code repository where a developer accidentally committed a configuration file. The firm loses 2.3 million customer records. The cloud provider's infrastructure was never compromised. Every failure was in customer-controlled configuration.
---
Cloud misconfiguration is the leading cause of cloud security incidents. The Verizon Data Breach Investigations Report consistently identifies misconfiguration as one of the top action categories in confirmed breaches. UpGuard, Rapid7, and other security research firms regularly discover publicly exposed storage buckets containing sensitive data from organizations that had no idea the data was accessible.
The 2019 Capital One breach is the most widely cited cloud security incident. An attacker exploited a misconfigured web application firewall to perform a server-side request forgery attack, accessed the EC2 instance metadata service, retrieved temporary credentials from an overly permissive IAM role, and exfiltrated over 100 million customer records from S3. Capital One was running on AWS. AWS was not breached. Every exploited control was Capital One's responsibility under the shared responsibility model.
Common Misconceptions
The most dangerous misconception in cloud security is that the cloud provider handles security. This is partially true and entirely misleading. Providers handle physical security, hypervisor security, and the security of their managed services. Customers handle identity, configuration, data, and application security. Conflating these responsibilities leads directly to the conditions that produced the Capital One breach and thousands of smaller, unreported incidents.
A second misconception is that cloud environments are inherently less secure than on-premises infrastructure. They are neither more nor less secure by default. They are different. A well-configured cloud environment with enforced MFA, least-privilege IAM, encrypted storage, centralized logging, and automated compliance checking is more secure than most on-premises environments. A poorly configured cloud environment with public storage, weak credentials, and no logging is significantly more dangerous because the attack surface is internet-facing by default.
For compliance purposes, the shift to cloud does not eliminate regulatory obligations. HIPAA, PCI DSS, SOC 2, and GDPR all apply to cloud environments. Most major cloud providers offer compliance documentation and certifications, but provider compliance does not equal customer compliance. Organizations must implement the required controls within their cloud tenancy.
---
The Cyber Defense Accelerator approaches cloud security through the Sovereign Posture and Hygiene (SPH) domain of its Planetary Defense Model. SPH addresses the foundational question: does the organization have continuous, reliable control over its own environment? Cloud computing creates a specific SPH challenge because the environment extends beyond physical boundaries and changes continuously through automated provisioning, scaling, and deprovisioning.
CDA's methodology, Autonomous Posture Command (APC), operates on the principle that "Your posture adapts. Your hygiene never sleeps." In cloud environments, this is not a metaphor; it is an operational requirement. Cloud infrastructure changes at machine speed. A developer can provision an insecure resource in seconds. Manual security review cannot keep pace. APC in the cloud context means automated policy enforcement, continuous configuration assessment, and real-time remediation or alerting when configurations drift from approved baselines.
Where many organizations treat cloud security as a periodic audit function, CDA treats it as a continuous control. This means cloud security posture management (CSPM) tools are not optional additions; they are baseline requirements. Every cloud account must have logging enabled and connected to a central SIEM. Every storage resource must be assessed for public accessibility. Every IAM policy must be reviewed for excessive permissions. These checks run continuously, not quarterly.
CDA also addresses the multi-cloud reality. Most organizations now operate across AWS, Azure, and Google Cloud simultaneously, each with its own IAM model, logging format, and security tooling. SPH requires a unified visibility layer that normalizes findings across providers so that no account or service exists outside of monitoring coverage.
The practical output of APC in cloud environments is a continuously updated posture score with actionable findings prioritized by risk, not just by severity. A critical finding in a development account with no sensitive data receives different treatment than a medium finding in a production account storing regulated customer data. Context drives prioritization, and prioritization drives action.
---
---
---