Cloud Security: Shared Responsibility, IaaS vs PaaS vs SaaS, Deployment Models

Cloud computing is a model for delivering computing resources - servers, storage, networks, applications - as an on-demand service over a network, rather than as hardware you buy and run yourself. The definition the CC exam draws on comes from NIST, which lists five essential characteristics. If a service has all five, it is cloud computing; if it is missing one, it is just outsourced hosting.

The five characteristics are:

• On-demand self-service. You provision resources yourself, when you need them, through a portal or API - without phoning a salesperson or filing a ticket and waiting for a human to rack a server.
• Broad network access. Resources are reachable over standard networks from standard clients: laptops, phones, tablets, other servers. You are not tied to one building or one dedicated line.
• Resource pooling. The provider serves many customers from one shared pool of hardware, assigning and reassigning capacity dynamically. Multiple tenants share the same physical infrastructure, which is why isolation between tenants matters so much to cloud security: pooling is the characteristic that creates cross-tenant risk, and keeping tenants separated on shared hosts is the provider's job.
• Rapid elasticity. Capacity scales up and down quickly - sometimes automatically - to match demand. From the customer's view, resources appear effectively unlimited.
• Measured service. Usage is metered, monitored, and reported, and you pay for what you consume, the way you pay for electricity.

To recognize a characteristic from a description, ask what the description is about. Who starts provisioning (the customer, with no human at the provider) is on-demand self-service. How the service is reached (standard networks, any common device, rather than one dedicated line or a proprietary client) is broad network access. Who shares the hardware (many tenants on one pool) is resource pooling. How capacity follows demand (adding resources as load rises and releasing them as it falls, instead of sizing permanently for the peak) is rapid elasticity. How usage is counted (metered, monitored and reported, so consumption is visible and can be billed per use) is measured service. Because all five are required, a service that lacks any one of them - for example, one reachable only through a single dedicated connection - does not meet the NIST definition, however modern its hardware.

Cloud services are sold in three layered models, distinguished by how much of the technology stack the provider manages for you.

IaaS (Infrastructure as a Service) gives you the raw building blocks: virtual machines, storage volumes, and networks. The provider owns the data centers, physical servers, and virtualization layer; you install and manage the operating systems, middleware, applications, and data yourself. IaaS is the most flexible model and the closest to running your own data center - which is exactly why it leaves the most security work on your plate. Renting virtual machines from a cloud provider is the classic IaaS example.

PaaS (Platform as a Service) gives developers a managed platform to build and run applications on. The provider manages everything up through the operating system and runtime - patching, scaling, and maintaining the platform - while you bring your application code and data. A managed database service or a managed application hosting environment where you deploy code without touching servers is PaaS.

SaaS (Software as a Service) delivers a complete, ready-to-use application over the network, typically through a browser. The provider runs the entire stack, from hardware up through the application itself; you manage only your data, your users, and your settings inside the app. Web-based email, office suites, and CRM applications are the standard SaaS examples.

A memory hook: the more "as a Service" letters sit toward the top of the stack, the less you manage. IaaS hands you infrastructure; SaaS hands you finished software.

While service models describe what you rent, deployment models describe who the cloud is built for and who shares it. The CC exam recognizes four.

Public cloud is infrastructure owned and operated by a provider and offered to the general public. Many unrelated customers - tenants - share the same pooled hardware, logically isolated from one another. With no hardware to buy and a huge shared pool behind it, it is the cheapest and most scalable model, and it is what most people mean when they say "the cloud."

Private cloud is cloud infrastructure operated for a single organization. It can sit in the organization's own data center or be hosted by a third party, but either way the resources are dedicated to one customer. Location does not decide the model; exclusivity does. Cloud infrastructure dedicated to one organization remains a private cloud whether it runs on premises or off premises with a third party. Organizations choose private cloud for tighter control, custom security requirements, or regulatory obligations - at higher cost and with less elasticity than public cloud.

Hybrid cloud combines two or more distinct clouds bound together so data and applications can move between them. Private plus public is the most common pairing, but NIST allows any combination of distinct private, community or public infrastructures - what makes it hybrid is that separate clouds are bound together, not which types they are. A common pattern keeps sensitive workloads in the private cloud while using public cloud capacity for less sensitive workloads or overflow demand. When a question describes "bursting" to a public cloud during peak load while keeping core systems in-house, that is hybrid.

Community cloud is shared by several organizations that have common requirements - the same regulatory regime, mission, or security needs. Think of a group of hospitals or government agencies sharing infrastructure built to their common compliance standard. Costs and governance are shared among the community members rather than borne by one organization or spread across the general public. To identify the model, look at who the infrastructure serves: one organization means private, the general public means public, a defined group with shared concerns means community, and two or more of these joined so workloads move between them means hybrid.

When you move workloads to a cloud provider, you outsource operations - but you never outsource accountability. The shared responsibility model is the industry's standard answer to the question "who secures what?" and it splits cleanly into two halves.

The provider is responsible for security OF the cloud. That means the physical layer and the infrastructure the service runs on: data center facilities, physical access controls, power and cooling, the hardware, the host network, and the virtualization layer that keeps tenants isolated from each other. You cannot patch the provider's hypervisor or walk their data center floor, so those duties can only sit with them.

Resource pooling is where this matters most. Because unrelated customers share physical hosts, a weakness in the virtualization layer that breaks the separation between tenants is a provider failure, and fixing it is the provider's duty in every service model. Paying for dedicated hosts gives a customer hardware no other tenant uses, but it does not hand over the building: physical access to the data center is still controlled by the provider.

The customer is responsible for security IN the cloud. That means everything you put into the service and every choice you make about it: your data and its classification and encryption, your user identities and their credentials and permissions, your access policies, and the configuration of the services you use. The provider gives you the controls; whether they are turned on, and turned on correctly, is your job.

Two consequences follow. First, a breach caused by a weak customer password or a storage service the customer left open to the internet is the customer's failure, not the provider's - the provider's infrastructure worked exactly as configured. Second, contracts and service level agreements can assign operational duties, but legal and regulatory accountability for personal data stays with the organization that collected it. Any claim that moving to the cloud transfers responsibility for the organization's data to the provider is false.

The shared responsibility line is not fixed - it slides with the service model. The rule to memorize: the more the provider manages, the more security responsibility the provider absorbs. IaaS puts the most responsibility on the customer; SaaS puts the least; PaaS sits between.

Read the table bottom-up and one row never changes hands: data, identities, access, and configuration belong to the customer in every model. Even in SaaS, where the provider runs the whole application, you still decide who gets accounts, what permissions they hold, whether multi-factor authentication is enforced, what data you upload, and how sharing settings are configured.

The practical differences are worth one pass each. In IaaS, you patch the operating systems on your virtual machines - miss a patch and the resulting compromise is on you. In PaaS, the provider patches the OS and runtime, but an insecure application you deploy on that platform is still your flaw. In SaaS, you cannot patch anything, so your security work concentrates entirely on identity, access, and data handling. The general principle: responsibility follows the layer, not the incident. One incident can involve failures on both sides of the line, and each party remediates the layers it owns. Changing service model moves only the layers the provider newly manages - moving up the stack hands over operating system and runtime, never data, identities or access. Even in SaaS, where the application itself is the provider's to secure and fix, account lifecycle (creating, reviewing and removing users) remains the customer's.

If you remember one sentence from this lesson, make it this one: the customer is always responsible for their data and their identities, in every cloud service model. The exam returns to this point repeatedly because it is where real-world cloud breaches actually happen.

Owning your data means deciding how it is classified, which of it may go to the cloud at all, whether it is encrypted and who holds the keys, how long it is retained, and how it is destroyed. Owning your identities means managing user accounts and their lifecycle, enforcing strong authentication (including multi-factor authentication), and applying least privilege so each account holds only the permissions its role requires. Owning your configuration means reviewing the security settings of every cloud service you consume - default settings are chosen for convenience, not for your risk profile.

Most publicized cloud data exposures are not provider infrastructure failures. They are customer-side misconfigurations: storage buckets set to public access, databases deployed without authentication, over-privileged accounts with stolen credentials and no second factor. The shared responsibility model explains why the provider's compliance certifications did not prevent any of those incidents - the failure sat on the customer's side of the line.

Three duties are easy to assume the provider covers, and it usually does not:

• Backup and recovery of your own data. A provider's recovery commitments protect its platform and infrastructure. They are not a promise to recover your own data from your own mistakes or misuse, unless the contract explicitly says so. If it does not, keeping recoverable copies of your data is your job.
• Audit evidence and log retention. A provider may keep platform logs for a short period for its own operations. That does not meet your legal, regulatory or audit retention needs. You must collect and retain your own sign-in and audit records for as long as your obligations require.
• Protection against a misused valid login. Provider encryption at rest protects data on disks and media. It does nothing when an attacker signs in with a real, phished customer password, because the service decrypts data for any authenticated user. Strong authentication such as multi-factor authentication is the control for that risk, and it is the customer's.

A service level agreement (SLA) is the contract document that states measurable service targets - availability, support response times - and the remedies owed when the provider misses them, usually service credits against the bill. The other agreements around a cloud service do different jobs, and confusing them is a common mistake.

Contracts and SLAs assign operational duties, so reading what the provider does and does not commit to is itself a customer responsibility: whatever the agreement leaves out - backups of your data, log retention, account management - should be assumed to stay with you. And no agreement moves legal accountability for the data away from the organization that collected it.

Work through a typical scenario. A company uses a public IaaS provider. An administrator uploads a customer database export to a cloud storage bucket and, to make a one-off transfer easier, sets the bucket's access policy to allow public read. Weeks later a researcher finds the bucket with an internet scan and the customer data is exposed. Who is responsible?

The customer. The provider's infrastructure performed exactly as configured: physical security held, tenant isolation held, the storage service enforced the policy it was given. The failure was a customer-side configuration choice about customer-owned data - squarely on the customer's side of the shared responsibility line. The correct preventive controls are also customer-side: restrictive default access policies, configuration review, least privilege for the administrator, and encryption of sensitive data before upload.

Now flip the scenario. If attackers had breached the provider's data center and stolen physical drives, or broken the isolation between tenants at the virtualization layer, responsibility would sit with the provider - those layers are theirs in every service model.

The same reasoning settles any cloud incident. Find the layer where the failure happened - facility, hardware, virtualization, operating system, runtime, application, or data, identities and configuration - then place that layer on the correct side of the line for the service model in use. Weak or missing authentication on customer accounts is a customer-side identity failure in every model, whatever the provider's encryption or availability commitments say.