Cloud Architectures (SaaS, PaaS, IaaS)

Why This Topic Matters for the CSSLP
Modern software is rarely built and deployed on hardware the development organization fully owns. The CSSLP's Secure Software Architecture and Design domain expects you to understand how the choice of cloud service model changes who is responsible for which security controls, how the attack surface shifts, and how architectural decisions (data placement, identity, encryption, logging, tenancy) must adapt. Exam questions in this area test whether you can reason about the shared responsibility model, select the correct service model for a scenario, and identify the security concerns that are unique to multi-tenant, provider-operated environments.

What Cloud Computing Is
NIST SP 800-145 defines cloud computing 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 provider interaction. NIST identifies five essential characteristics:
1. On-demand self-service – consumers provision resources without human interaction with the provider.
2. Broad network access – capabilities are available over the network through standard mechanisms.
3. Resource pooling – multi-tenant model where resources are dynamically assigned; the consumer generally has no control over exact physical location.
4. Rapid elasticity – resources scale out and in quickly, appearing unlimited to the consumer.
5. Measured service – usage is metered, monitored, and reported (pay-per-use).

The Three Service Models

1. Infrastructure as a Service (IaaS)
The provider delivers fundamental computing resources: virtual machines, storage, networks, and load balancers. The consumer deploys and runs arbitrary software, including operating systems and applications.
• Provider is responsible for: physical facilities, hardware, hypervisor/virtualization layer, host networking.
• Consumer is responsible for: guest operating system patching and hardening, middleware, runtime, applications, data, identity and access management within the environment, network security groups/firewall rules, encryption of data at rest and in transit.
• Examples: Amazon EC2, Azure Virtual Machines, Google Compute Engine.
• Key security concerns: hypervisor escape, VM sprawl, insecure images and snapshots, misconfigured storage buckets, unpatched guest OS, exposed management ports, key management.

2. Platform as a Service (PaaS)
The provider delivers a platform (runtime, middleware, databases, development tools) on which consumers deploy their own applications. The consumer does not manage the underlying infrastructure or operating system but controls the deployed applications and possibly configuration settings of the hosting environment.
• Provider is responsible for: everything in IaaS plus the operating system, runtime, middleware, and platform patching.
• Consumer is responsible for: application code, application-level security controls, data, user identity and access, secure configuration of platform features.
• Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku, managed database services.
• Key security concerns: insecure application code (OWASP Top 10 issues are fully the consumer's problem), vendor lock-in due to proprietary APIs, secrets stored in configuration, insufficient logging access, shared runtime isolation.

3. Software as a Service (SaaS)
The provider delivers a complete application running on cloud infrastructure, accessible through a web browser or API. The consumer manages only limited user-specific configuration settings.
• Provider is responsible for: the entire stack – infrastructure, platform, application code, application patching, availability.
• Consumer is responsible for: data classification and handling, user access and identity management (who gets accounts, roles, MFA enforcement), configuration choices offered by the application, endpoint security, and ensuring the service meets regulatory requirements.
• Examples: Microsoft 365, Salesforce, Google Workspace, Dropbox.
• Key security concerns: loss of control over data location and processing, data commingling with other tenants, limited visibility into provider security, dependence on provider's incident response, account hijacking, data exfiltration via integrations, regulatory/compliance assurance.

The Shared Responsibility Model – The Heart of Exam Questions
The cleanest way to remember the three models is as a sliding scale of control versus responsibility:
• IaaS: Consumer has the most control and the most security responsibility.
• PaaS: Responsibility is split roughly in the middle; consumer owns the application and data.
• SaaS: Consumer has the least control and the least responsibility, but never zero – data and identity remain the consumer's responsibility in every model.

A simple mnemonic for the stack, bottom to top: Facilities → Hardware → Virtualization → OS → Middleware/Runtime → Application → Data. In IaaS the consumer takes over at the OS layer; in PaaS at the Application layer; in SaaS the consumer manages only Data and access to it. Regardless of model, the data owner is always accountable for the data. Accountability cannot be outsourced even when responsibility for operating controls is.

Deployment Models (Frequently Paired with Service Models)
• Public cloud – infrastructure owned by a provider and shared among many organizations; greatest multi-tenancy risk.
• Private cloud – operated solely for one organization, on or off premises; highest control, highest cost.
• Community cloud – shared by several organizations with common concerns (e.g., government agencies, healthcare consortium).
• Hybrid cloud – two or more models bound together with technology enabling portability (e.g., cloud bursting). Introduces complexity in consistent policy enforcement and secure interconnection.

How Cloud Architecture Affects Secure Design

Multi-tenancy and isolation. Resource pooling means your workload shares physical hardware with strangers. Design for the assumption that isolation can fail: encrypt data at rest with keys you control, avoid relying solely on provider isolation for sensitive data separation, and prefer dedicated/single-tenant options when regulations demand them.

Data security. Classify data before moving it to the cloud. Apply encryption in transit (TLS) and at rest. Consider Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK) so the provider cannot decrypt data unilaterally. Address data residency and sovereignty – where data physically sits determines which laws apply. Plan for data remanence and secure deletion when leaving a provider; crypto-shredding (destroying the key) is the practical approach.

Identity and access management. Cloud makes identity the new perimeter. Use federation (SAML, OpenID Connect), enforce MFA, apply least privilege through role-based access, protect root/administrative accounts, and rotate API keys and service credentials. Many real-world cloud breaches trace back to leaked credentials or over-permissive roles rather than provider failures.

Secure APIs. Cloud services are consumed and managed via APIs. API security (authentication, authorization, input validation, rate limiting, transport encryption) is a core design concern, especially for PaaS and SaaS integrations.

Logging, monitoring, and forensics. Visibility decreases as you move from IaaS to SaaS. Architects must ensure contractual and technical access to logs, understand what the provider will and will not share during an incident, and design application-level logging to compensate for lost infrastructure visibility.

Availability and resilience. Design across availability zones or regions, understand the provider's SLA, and recognize that the consumer is responsible for backups and recovery of their own data even in SaaS unless the contract states otherwise.

Vendor lock-in and portability. Proprietary PaaS services and SaaS data formats create exit barriers. Favor open standards, containerization, and documented data export mechanisms to preserve portability.

Contracts, SLAs, and governance. Security requirements that cannot be enforced technically must be enforced contractually: right to audit (or acceptance of third-party attestations such as SOC 2 Type II, ISO/IEC 27001, FedRAMP, CSA STAR), breach notification timelines, data ownership clauses, subprocessor disclosure, and termination/data return provisions.

Related Concepts You Should Recognize
• Cloud Access Security Broker (CASB) – an enforcement point between users and cloud services providing visibility, data security, threat protection, and compliance, particularly for SaaS.
• Function as a Service (FaaS) / Serverless – an extension of PaaS where the consumer supplies only code functions; the provider manages everything else. Security focus shifts almost entirely to code, dependencies, permissions, and event-source validation.
• Containers as a Service (CaaS) – sits between IaaS and PaaS; the consumer manages container images and orchestration configuration.
• Cloud Security Alliance (CSA) Cloud Controls Matrix – a control framework mapping security requirements across service models; often referenced for due diligence.
• NIST SP 800-144/800-145/800-146 – guidelines and definitions commonly cited in exam questions.

Exam Tips: Answering Questions on Cloud Architectures (SaaS, PaaS, IaaS)

1. Identify the service model first, then map responsibility. When a scenario describes what the organization controls (VMs? just code? only user accounts?), that tells you the model. IaaS = you manage the OS upward; PaaS = you manage the application and data; SaaS = you manage data and access only. Once the model is identified, the "who is responsible" answer usually follows directly.

2. Remember that data and identity are always the consumer's job. If an answer choice suggests the SaaS provider is responsible for classifying your data, deciding who gets access, or meeting your regulatory obligations, it is almost certainly wrong. Accountability for data never transfers.

3. Distinguish responsibility from accountability. You can delegate operation of controls (responsibility) to a provider, but the data owner retains accountability. Questions phrased around "who is ultimately accountable" are pointing at the consumer organization.

4. Know the NIST five essential characteristics and four deployment models. Questions may ask which characteristic enables pay-per-use (measured service), which describes scaling (rapid elasticity), or which deployment model suits organizations with shared compliance needs (community cloud).

5. Watch for the "loss of control" theme. As you move toward SaaS, you lose visibility into infrastructure, logs, and incident handling. When a question asks about the primary security concern of adopting SaaS, answers involving reduced visibility, data location, multi-tenancy, or dependence on provider controls are typically correct.

6. Think "contract" when technology cannot help. If the scenario involves assurance about provider practices, breach notification, or audit rights, the best answer is usually a contractual/SLA control or reliance on independent attestations (SOC 2, ISO 27001, FedRAMP) rather than a technical control you cannot implement in someone else's data center.

7. For IaaS questions, think traditional hardening in a virtual world. Patching the guest OS, hardening images, restricting management ports, configuring security groups, and protecting hypervisor access are consumer tasks. If the question mentions hypervisor vulnerabilities, remember the hypervisor itself is the provider's responsibility, but isolation failure risk is something the consumer must design around (encryption, data segregation).

8. For PaaS questions, think secure coding and configuration. The OS and runtime are patched by the provider; injection flaws, broken authentication, hard-coded secrets, and insecure platform configuration are the consumer's problems. Vendor lock-in is the classic non-security-but-still-architectural PaaS concern.

9. Encryption and key management are high-yield. If a question asks how to maintain confidentiality when the provider could access data, the answer involves client-side encryption or customer-managed/held keys (BYOK/HYOK). If it asks how to ensure data is unrecoverable at contract termination, think crypto-shredding.

10. Eliminate absolutes. Answer choices stating that the provider handles "all" security or that the consumer has "no" responsibility in SaaS are distractors. The shared responsibility model is a spectrum, not an all-or-nothing split.

11. Apply the CSSLP mindset: build security in early. When asked when cloud security requirements should be defined, the answer is during requirements and architecture/design – before selecting a provider or service model – not after deployment.

12. Read for the "most" or "best" qualifier. Several options may be partially correct. Choose the one that addresses the root issue at the right layer of responsibility for the stated service model, and prefer governance or design-level answers over narrow technical fixes when the question is framed at the architectural level.

Quick Reference Summary
• IaaS: VMs, storage, networks. Consumer secures OS, middleware, apps, data, IAM. Most control, most work.
• PaaS: Managed runtime/platform. Consumer secures application code, configuration, data, IAM. Lock-in risk.
• SaaS: Complete application. Consumer secures data, user access, configuration choices. Least control, least visibility.
• Always the consumer's: data classification, data ownership, identity and access decisions, regulatory accountability, endpoint security, due diligence on the provider.
• Always the provider's: physical security, hardware, hypervisor, and whatever layers sit below the consumer's entry point in the chosen model.

Mastering this topic comes down to one disciplined habit: for any scenario, determine the service model, draw the responsibility line, and then evaluate each answer against where that line falls. Do that consistently and cloud architecture questions become some of the most predictable on the CSSLP exam.