What is Cloud Security?

The Shared Responsibility Model

The shared responsibility model defines which security obligations belong to the cloud provider and which belong to the customer. The exact division depends on the service model.

Infrastructure as a Service (IaaS)

In IaaS environments — AWS EC2, Azure Virtual Machines, GCP Compute Engine — the provider is responsible for the physical data center, networking hardware, hypervisor, and the virtualization layer. The customer is responsible for the operating system, applications, data, runtime, middleware, and network configuration within the virtual machine. The customer patches the OS, manages firewall rules (security groups), controls access, and protects application-layer security. The provider does none of this.

Platform as a Service (PaaS)

In PaaS environments — Azure App Service, AWS Elastic Beanstalk, GCP App Engine — the provider manages the OS and runtime in addition to the infrastructure. The customer is responsible for application code and data. The customer still controls access management, network configuration, and application security.

Software as a Service (SaaS)

In SaaS environments — Microsoft 365, Salesforce, Workday — the provider manages everything except the data the customer puts into the service and how the customer configures access to it. The customer is responsible for identity and access management configuration, data classification and governance, and the security settings available within the SaaS platform. The most dangerous misconception about SaaS security is that the provider is responsible for data backup, data governance, and configuration security — they are not.

The Most Common Cloud Security Failures

Identity and Access Management Misconfiguration

The most prevalent cloud security issue across all cloud environments is identity and access management misconfiguration. Overly permissive IAM policies that grant broad access to cloud resources when narrow permissions would suffice, service accounts with administrative privileges used for routine operations, access keys stored in code repositories or environment variables where they are discovered by automated scanners, and the absence of MFA on cloud management console accounts are all consistently identified in cloud security assessments. In 2024, the Snowflake customer breach — which affected Ticketmaster, Santander, and dozens of other organizations — was caused entirely by credential compromise in the absence of MFA on Snowflake accounts.

Publicly Exposed Storage

Misconfigured cloud storage — S3 buckets, Azure Blob containers, GCP Cloud Storage buckets — that is inadvertently made publicly accessible is one of the most common and most damaging cloud security failures. Sensitive data placed in storage that someone configured as publicly readable is accessible to anyone on the internet without authentication. Automated scanning tools continuously crawl cloud storage for publicly accessible buckets, meaning misconfigured storage is discovered quickly. High-profile breaches caused by exposed S3 buckets include Capital One (2019, 100 million records), Twitch (2021, internal source code and financial data), and dozens of government and healthcare organizations.

Logging and Monitoring Gaps

Cloud environments generate comprehensive audit logs — CloudTrail in AWS, Activity Log in Azure, Cloud Audit Logs in GCP — that record every API call, configuration change, and authentication event. These logs are the primary data source for detecting unauthorized activity in cloud environments. In most mid-market cloud deployments, these logs are either not enabled, not centralized, or not monitored. An attacker who gains cloud account access in an environment without logging enabled can operate without generating any forensic evidence of their activity.

Cloud Security for PE Portfolio Companies

The Configuration Drift Problem

Cloud environments change continuously. Developers provision new resources, modify access policies, create service accounts, and adjust network configurations as part of normal operations. Each change introduces the potential for misconfiguration. Cloud Security Posture Management (CSPM) tools continuously assess cloud environment configuration against security benchmarks — CIS benchmarks, provider-specific best practices — and alert on deviations. Without continuous configuration monitoring, cloud security posture at any given time reflects the accumulated result of every configuration change made since the environment was provisioned.

M&A Due Diligence in Cloud Environments

Cloud environment security assessment in M&A due diligence requires different tools and techniques than traditional infrastructure assessment. Read-only access to the target's cloud management console or equivalent API access enables rapid assessment of IAM configuration, network security group settings, storage bucket access policies, logging configuration, and encryption settings. In Cloudskope's due diligence engagements, cloud configuration review consistently surfaces material findings — publicly accessible storage, administrative accounts without MFA, service accounts with excessive permissions — that are not visible in traditional infrastructure assessments.

Real-World Example: Capital One — A Misconfigured Firewall and 100 Million Records

The 2019 Capital One breach exposed over 100 million credit card applications stored in AWS S3. The attacker, a former AWS employee, exploited a misconfigured Web Application Firewall that allowed server-side request forgery — sending a crafted request that caused the WAF server to retrieve AWS instance metadata, including temporary IAM credentials. Those credentials had excessive permissions that allowed access to the S3 buckets containing customer data. The cloud provider — AWS — was not breached. The data was not in a publicly accessible bucket. The failure was a customer-side misconfiguration: an overly permissive IAM role attached to a WAF with a configuration vulnerability. Capital One paid $190 million in settlements.