Shared Responsibility Model: IaaS, PaaS, SaaS

Cloud services are delivered in three primary models, each offering a different level of abstraction. Infrastructure as a Service (IaaS) provides raw compute, storage, and networking. Platform as a Service (PaaS) adds OS, middleware, and runtime environments. Software as a Service (SaaS) delivers fully functional applications over the internet. Understanding these models is essential because the security responsibilities differ dramatically across them.

The shared responsibility model defines which security tasks are the cloud provider's obligation and which belong to the customer. The model is often summarized as: the provider is responsible for security of the cloud (physical datacenters, hypervisors, network infrastructure), while the customer is responsible for security in the cloud (data, access management, application security, and configuration). Misunderstanding this boundary is a leading cause of cloud security incidents.

In IaaS, the customer assumes the most security responsibility. The cloud provider secures the physical infrastructure, hypervisor, and network fabric. The customer is responsible for: OS installation, patching, and hardening; runtime and middleware configuration; application security; network security group rules; IAM policies and user management; data encryption at rest and in transit; and compliance configuration. IaaS gives maximum control but requires maximum security effort.

In PaaS, the provider takes over OS and runtime management. The customer no longer patches the operating system or manages the middleware — the provider handles that. However, the customer remains responsible for: application code security (no SQLi, XSS, etc.), data classification and encryption, identity and access management, application configuration (environment variables, secrets management), and API security. PaaS shifts some burden to the provider while customers focus on application logic.

In SaaS, the provider manages nearly everything. The customer's primary security responsibilities are: access management (who has accounts, enforcing MFA, reviewing permissions), data governance (what data is uploaded, how long it is retained), configuration security (privacy settings, sharing permissions, third-party integrations), and acceptable use compliance. Many SaaS breaches stem from misconfigured sharing settings or excessive third-party app permissions rather than provider failures.

Some controls are shared between provider and customer. For example, encryption: the cloud provider may offer encryption services (KMS, default encryption) but the customer must enable them, configure key management, and choose appropriate algorithms. Similarly, identity: the provider supplies IAM tools, but the customer must configure least-privilege policies and enforce MFA. Assuming the provider handles a shared control and not configuring it is a common and dangerous mistake.

The shared responsibility model fails most often through customer misconfiguration, not provider failures. Classic examples: S3 buckets left publicly accessible (Capital One breach 2019, 100M records exposed), overly permissive IAM roles that allow privilege escalation, security groups with inbound 0.0.0.0/0 rules on sensitive ports, and default credentials left unchanged on cloud-deployed databases. The provider's underlying infrastructure was secure; the customer's configuration was not.

A key challenge in the shared model is visibility. In on-premises environments, security teams control all logging. In the cloud, provider infrastructure logs may not be accessible. Customers must enable cloud-native logging services: AWS CloudTrail, Azure Monitor, and GCP Cloud Audit Logs capture API calls and configuration changes. Without enabling these services, an organization has no audit trail of who did what in their cloud environment — a major compliance and forensic gap.

When organizations use Managed Service Providers (MSPs) to operate cloud environments, responsibility becomes a three-way split. The customer must ensure contracts (SLAs and DPAs) clearly define security obligations. Third-party cloud apps accessed through SaaS introduce additional complexity: OAuth consent granted to an overly permissive app gives that app access to your data. Reviewing and regularly auditing third-party OAuth consents is part of SaaS security hygiene.

Compliance requirements do not disappear because workloads moved to the cloud. HIPAA requires a Business Associate Agreement (BAA) with cloud providers handling PHI — AWS, Azure, and GCP all offer BAAs. PCI-DSS requires the cloud environment to be within the assessment scope; shared responsibility matrices from providers document which PCI controls are satisfied. Organizations must understand what their provider covers versus what they must implement themselves to pass audits.

The shared responsibility model has legal weight. Cloud provider Terms of Service and Service Level Agreements (SLAs) specify availability guarantees and exclusions. Data Processing Agreements (DPAs) under GDPR define processor obligations. If a breach occurs due to provider-side failure, the customer has grounds for remedies under the SLA. If the breach is due to customer misconfiguration, the provider bears no liability. Understanding contracts is as important as understanding technical controls.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: the shared responsibility model defines provider vs. customer security obligations across IaaS, PaaS, and SaaS, customers carry the most security responsibility in IaaS and the least in SaaS, but always own access management and data governance, and customer misconfiguration — not provider failure — is the leading cause of cloud breaches. Next up we explore cloud storage security and data exposure risks.