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.
• 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.

The exam tests these at recognition depth. A question describes one characteristic in plain words - "a customer provisions a new server through a web portal with no human interaction" - and asks you to name it. Learn the five names and one-line meanings, and match trigger phrases: "self-provision" points to on-demand self-service, "shared among tenants" to resource pooling, "scales automatically with demand" to rapid elasticity, "pay per use" to measured service.

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. 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. 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 - typically private plus public - bound together so data and applications can move between them. 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. Exam questions describe the tenant population and ask for the model: one organization means private, everyone means public, a mix bound together means hybrid, and a defined group with shared concerns means community.

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.

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. On the exam, any answer choice suggesting that "moving to the cloud transfers responsibility for our data to the provider" is wrong, every time.

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. Exam questions exploit exactly these edges: "who patches the OS of a virtual machine in IaaS?" (the customer) and "who patches the platform in PaaS?" (the provider).

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.

This is also why cloud contracts matter to security. A service level agreement (SLA) defines what the provider commits to - availability targets, support response, sometimes security obligations - and what remedies you have if they miss. Reading what the provider does and does not commit to is itself a customer responsibility: whatever the SLA leaves out is, by default, yours.

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 exam probes this topic in three predictable shapes. First, definition matching: name the characteristic, service model, or deployment model that a one-sentence description points to. Second, responsibility assignment: given a model and a stack layer, say whose job it is - remember that the answer for data and identities is always "customer." Third, scenario judgment like the bucket story: identify whose side of the line a failure occurred on. If you can place any layer of the stack on the right side of the line for IaaS, PaaS, and SaaS, you can answer all three shapes.