From the NIST five essential characteristics to IaaS, PaaS, SaaS and beyond — the building blocks every cloud security practitioner must understand before touching a single control.
⚡ Quick Bite · 20s
Identity IS the new perimeter — IAM and the principle of least privilege as the foundation of Zero Trust cloud architecture.
Watch this 20-second summary before diving into the full article. Sign in to earn 5 leaderboard points.
The National Institute of Standards and Technology (NIST) defines cloud computing in SP 800-145 as "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction." That sentence is dense, so let us unpack it through the five essential characteristics that make a service genuinely cloud-based.
| Characteristic | What It Means | Security Implication |
|---|---|---|
| On-demand self-service | Provision compute, storage, and network without human interaction | Developers can spin up insecure resources without IT review |
| Broad network access | Available over the network from any standard device | Attack surface spans all devices and networks |
| Resource pooling | Provider serves multiple customers from shared infrastructure | Data co-residence; noisy-neighbour and side-channel risks |
| Rapid elasticity | Scale up and down automatically | Ephemeral resources can disappear before forensic acquisition |
| Measured service | Usage is metered and billed | Compromised credentials lead to runaway billing (EDoS) |
From a security perspective, rapid elasticity and measured service together create the most dangerous combination: an attacker can consume resources at speed, generate massive cost, and destroy evidence as instances auto-terminate.
You get raw compute (VMs), storage (block/object), and networking. You are responsible for the operating system upward — patching, hardening, application security, and data protection. AWS EC2, Azure Virtual Machines, and GCP Compute Engine are the canonical examples.
The provider manages the OS, runtime, and middleware. You deploy code and data. AWS Elastic Beanstalk, Azure App Service, and GCP App Engine fall here. The security boundary narrows — but injection flaws and insecure application logic remain entirely yours.
The provider runs everything. You configure and use the application. Microsoft 365, Salesforce, and Google Workspace are SaaS. Misconfiguration of sharing settings, permissions, and data residency is the primary risk you own.
Beyond the NIST triad, modern cloud ecosystems include:
| Model | Example | Security Note |
|---|---|---|
| FaaS (Function as a Service) | AWS Lambda, Azure Functions | Short-lived; hard to monitor; cold-start injection risks |
| CaaS (Container as a Service) | AWS ECS/EKS, GKE | Image vulnerabilities, overprivileged service accounts |
| DBaaS (Database as a Service) | RDS, Cloud SQL, Cosmos DB | Encryption at rest defaults vary; audit logging must be enabled explicitly |
| SECaaS (Security as a Service) | Cloudflare, Zscaler | Third-party holds traffic; trust and SLA become security variables |
The shared responsibility model begins at the service-model boundary. Knowing exactly where your responsibility starts — whether at the hypervisor (IaaS), the application (PaaS), or just configuration (SaaS) — is the first skill a cloud security professional develops. Every later chapter in this course builds on that boundary.
Sign in to mark this article as read and track your progress.
