9.1 Cloud Computing Concepts

Why Cloud Concepts Matter on the CEH

Cloud Computing is a dedicated domain on the CEH v13 blueprint, and most questions in it are conceptual rather than command-driven. You will be asked to classify a service model from a scenario, identify which party owns a security duty under the shared responsibility model, or recognize a cloud-native technology such as a container or serverless function. Precise definitions earn more points here than any single tool, because the exam tests whether you understand who is responsible for what and where the trust boundaries lie. Get the vocabulary exact and the attack/defense sections (9.2 and 9.3) become straightforward.

The NIST Cloud Definition (SP 800-145)

The U.S. National Institute of Standards and Technology defines cloud computing in Special Publication 800-145 through five essential characteristics:

• On-demand self-service — a consumer provisions compute, storage, or network automatically, without human interaction from the provider.
• Broad network access — capabilities are available over the network through standard mechanisms (thin or thick clients).
• Resource pooling — the provider's resources serve multiple consumers using a multitenant model, with resources dynamically assigned (location independence).
• Rapid elasticity — capabilities scale out and in quickly, sometimes automatically, appearing unlimited to the consumer.
• Measured service — usage is metered, monitored, controlled, and billed (pay-as-you-go).

If a scenario lacks self-service or metering, it is not true cloud by this definition — a common distractor.

Service Models: IaaS, PaaS, SaaS

The three canonical service models differ by how much the consumer manages versus the provider.

The reliable exam rule: IaaS gives the customer the most control and therefore the most security responsibility; SaaS gives the least of both. PaaS sits in between. A related distractor: regardless of model, the customer always owns data classification, identity, and access policy — the provider never assumes those.

Deployment Models

NIST defines four deployment models:

• Public cloud — infrastructure is owned by a provider and shared by the general public over the internet.
• Private cloud — provisioned for a single organization; can be on-premises or hosted by a third party.
• Hybrid cloud — two or more distinct clouds bound together to enable data and application portability (for example, sensitive workloads on private, burst capacity on public — "cloud bursting").
• Community cloud — shared by several organizations with common concerns, such as a shared regulatory or compliance mandate.

Multitenancy and Virtualization

Multitenancy is the model where a single physical platform serves many isolated customers (tenants). Isolation is enforced by hypervisors, virtual networks, storage segmentation, and identity boundaries. The hypervisor (Virtual Machine Monitor) is the software layer that creates and runs virtual machines; a Type 1 hypervisor runs directly on bare-metal hardware (used in clouds), while a Type 2 hypervisor runs on top of a host OS.

Because tenants share hardware, weak tenant isolation — a hypervisor escape or a shared-resource leak — is the root cause of the most serious cloud attacks, and isolation is primarily the provider's duty.

Containers and Orchestration

Containers package an application together with its libraries and dependencies, then run as isolated processes that share the host operating-system kernel. They are far lighter than virtual machines because there is no per-container guest OS, so they start in seconds and pack densely onto a host. Linux primitives namespaces (isolate what a process can see) and cgroups (limit what it can use) provide the isolation.

Docker is the dominant container runtime; Kubernetes (K8s) is the dominant orchestration platform that schedules, scales, and networks containers across a cluster of nodes (pods are the smallest deployable unit).

Because containers share the kernel, isolation is weaker than a VM's — a kernel vulnerability or a privileged/misconfigured container can lead to container escape (covered in 9.2).

Serverless / Function as a Service

Serverless computing, also called Function as a Service (FaaS), abstracts the host entirely: the provider runs the customer's code only when an event triggers it, scales it automatically, and bills per invocation and execution time. The customer no longer patches an OS or manages servers, but still owns the function code, its third-party dependencies, and its permissions/IAM role. Over-permissive function roles and vulnerable dependencies are the recurring serverless risks.

Putting Responsibility Together

The single most-tested cloud idea is the shared responsibility model: the provider is always responsible for security of the cloud (hardware, hypervisor, physical facilities), and the customer is always responsible for security in the cloud (data, identities, access policy, and — depending on model — the OS and application). Moving from IaaS toward SaaS shifts more of the stack to the provider, but never the customer's data and identity duties. Keep this gradient in mind for every scenario question.