After completing this tutorial, you will be able to:
Cloud Computing has fundamentally transformed how organizations procure, deploy, and manage information technology resources. What was once a matter of capital expenditure—buying servers, storage arrays, and networking equipment—has become an operational expense, with compute, storage, and networking available on demand, over the internet, and with near-infinite scalability. This shift has enabled unprecedented agility, reduced time-to-market, and democratized access to enterprise-grade infrastructure. However, it has also introduced a new set of security challenges that require a fundamental rethinking of how we protect data, applications, and identities.
This tutorial, Tutorial 8.2: Cloud Computing Fundamentals and Security Foundations, is the first of three tutorials dedicated to cloud security within Unit 8. It serves as the foundational pillar upon which the subsequent tutorials (8.3 on Cloud Security Architecture and Controls, and 8.4 on Cloud Threats and Incident Response) are built. Without a solid grasp of what cloud Computing is, how it works, and the shared responsibility model, it is impossible to effectively secure cloud environments.
We begin by defining cloud Computing /strong> and unpacking its essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. These characteristics, as defined by NIST, are the bedrock of the cloud paradigm. We then explore the enabling technologies that make cloud Computing possible—notably virtualization and containerization—and examine the security implications of multi-tenancy and resource abstraction.
A significant portion of the tutorial is dedicated to the cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), and the newer models of Function as a Service (FaaS) and Serverless Computing Each model represents a different level of abstraction and a different division of responsibility between the cloud provider and the customer. Understanding these models is critical to understanding the shared responsibility model, which we will explore in depth.
We then survey the cloud deployment models: public, private, hybrid, multi-cloud, and community cloud. Each deployment model offers different trade-offs between cost, control, security, and compliance. We discuss the security implications of each and provide guidance on selecting the appropriate model for various scenarios.
Finally, we introduce the fundamentals of cloud security, including the security objectives (confidentiality, integrity, availability), the shared responsibility model in detail, and a high-level overview of cloud security architecture. We also touch on key security controls such as identity and access management (IAM), encryption, and network security, which will be explored in greater depth in Tutorial 8.3.
This tutorial is designed for students who are new to cloud Computing as well as those who have some experience but want to deepen their understanding of the security implications. By the end of this tutorial, you will have a comprehensive mental model of cloud Computing that will enable you to critically evaluate cloud security architectures, participate in security assessments, and make informed decisions about cloud adoption and migration.
The National Institute of Standards and Technology (NIST) provides the most widely accepted definition of cloud Computing (NIST SP 800-145):
"Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable Computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."
This definition encapsulates the essence of cloud Computing on-demand availability, broad network access, resource pooling, rapid elasticity, and measured service. These five characteristics, which we will examine in detail, are what distinguish cloud Computing from traditional, on-premises IT.
It is important to distinguish cloud Computing from other forms of outsourcing or hosting. While traditional hosting provides dedicated servers in a data center, cloud Computing provides dynamically scalable and metered resources that are self-serviceable and virtualized. The cloud is not a single technology but a paradigm that encompasses a family of technologies and operating models.
The concept of cloud Computing has roots in the 1960s, when computer scientist John McCarthy suggested that "computation may someday be organized as a public utility." The 1990s saw the emergence of grid Computing /strong> and utility Computing /strong>, where Computing resources were shared across organizations. However, it was the advent of virtualization and the internet in the early 2000s that made cloud Computing practical and commercially viable.
Amazon Web Services (AWS) launched in 2006 with its Elastic Compute Cloud (EC2) and Simple Storage Service (S3), marking the birth of the modern cloud era. Google and Microsoft followed with their own cloud platforms. Today, the "big three" cloud providers—AWS, Microsoft Azure, and Google Cloud Platform (GCP)— dominate the market, along with a growing ecosystem of specialized providers and regional players.
The evolution of cloud Computing can be viewed through the lens of abstraction: from physical servers to virtual machines (IaaS), to managed platforms (PaaS), to fully managed applications (SaaS), and now to event-driven, serverless Computing (FaaS). Each level of abstraction brings greater agility but also new security considerations.
The NIST definition identifies five essential characteristics of cloud Computing Understanding these characteristics is crucial because they directly influence the security posture of cloud environments.
A cloud consumer can unilaterally provision Computing capabilities—such as server time, network storage, or virtual machines—automatically and without requiring human interaction with the service provider. This is typically achieved through a web-based management console, an API, or a command-line interface.
Security implication: Self-service reduces the friction of provisioning, enabling rapid development and deployment. However, it also means that security controls must be automated and policy-driven to prevent misconfigurations. Without proper guardrails, self-service can lead to shadow IT, resource sprawl, and inadvertent exposure of sensitive data.
Cloud services are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations). This broad access is enabled by the internet and standardized protocols such as HTTP, REST, and WebSocket.
Security implication: Broad network access expands the attack surface. Cloud services are exposed to the public internet by default, making them targets for network-based attacks. Strong authentication, encryption in transit, and robust API security are essential to protect against unauthorized access and eavesdropping.
The cloud provider's Computing resources are pooled to serve multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically assigned and reassigned according to consumer demand. The consumer generally has no control over the exact location of the resources but may be able to specify location at a higher level of abstraction (e.g., region, availability zone).
Security implication: Resource pooling introduces the risk of side-channel attacks, where one tenant can infer information about another tenant by observing resource usage patterns. It also raises concerns about data co-location and the potential for data leakage across tenants. Isolation mechanisms—such as hardware virtualization, container sandboxing, and network segmentation—are critical to mitigate these risks.
Cloud resources can be rapidly and elastically provisioned—sometimes automatically—to scale out or scale in based on demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
Security implication: Elasticity introduces dynamicity that complicates security monitoring and policy enforcement. Resources that are created and destroyed frequently make it difficult to maintain a complete inventory of assets. Security controls must be infrastructure as code (IaC)-friendly and capable of continuous compliance monitoring in a rapidly changing environment. Additionally, scaling out increases the attack surface, as more endpoints become available.
Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, or active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and the consumer.
Security implication: Measured service enables cost monitoring and anomaly detection. Sudden spikes in resource usage can be an indicator of a security incident—for example, a crypto-mining attack that consumes excessive compute resources, or a data exfiltration attempt that generates unexpected outbound network traffic. Metering data can also be used for forensic analysis and compliance reporting.
| Characteristic | Description | Key Security Implication |
|---|---|---|
| On-Demand Self-Service | Users provision resources without human intervention | Requires automated security policies; risk of misconfiguration |
| Broad Network Access | Services accessible via standard network protocols | Expanded attack surface; need for encryption and strong authentication |
| Resource Pooling | Multi-tenant model with dynamic assignment of resources | Side-channel risks; isolation and data co-location concerns |
| Rapid Elasticity | Resources scale in/out automatically based on demand | Dynamic attack surface; continuous monitoring required |
| Measured Service | Usage metered and reported for transparency and cost control | Anomaly detection potential; forensic value of usage data |
Virtualization is the technology that makes cloud Computing possible. It abstracts physical hardware (servers, storage, networking) and presents it as a logical resource that can be partitioned, allocated, and managed independently. The hypervisor, or virtual machine monitor (VMM), is the software layer that enables this abstraction by running virtual machines (VMs) on a single physical host.
There are two primary types of hypervisors:
Beyond server virtualization, cloud Computing also leverages network virtualization (software-defined networking, SDN), storage virtualization, and containerization (e.g., Docker, Kubernetes). Containers provide a lightweight alternative to VMs by virtualizing at the operating system level, sharing the host kernel but isolating processes and file systems.
Multi-tenancy is a fundamental principle of cloud Computing where a single instance of a software application or infrastructure serves multiple tenants (customers). In the cloud, multi-tenancy is achieved through virtualization and resource sharing.
From a security perspective, multi-tenancy introduces the challenge of isolation. Tenants must be isolated from each other to ensure that one tenant cannot access, modify, or disrupt the resources or data of another tenant. Isolation mechanisms operate at multiple layers:
While virtualization enables cloud Computing it also introduces specific security risks:
Cloud providers invest heavily in securing their virtualization stacks, but customers also bear responsibility for securing their guest operating systems, applications, and data.
Resource abstraction is the process of hiding the underlying physical infrastructure from the consumer, presenting instead a standardized, logical interface. In cloud Computing abstraction occurs at multiple levels:
Abstraction enables portability, agility, and automation. However, it also introduces security challenges:
Cloud resource management encompasses the provisioning, monitoring, and optimization of cloud resources. Orchestration refers to the automated arrangement, coordination, and management of complex cloud systems and services. Key concepts include:
The NIST definition identifies three primary service models: IaaS, PaaS, and SaaS. Over time, additional models have emerged, including FaaS (Function as a Service) and Serverless Computing These models represent different levels of abstraction, with correspondingly different divisions of responsibility between the cloud provider and the customer.
IaaS provides virtualized Computing resources over the internet. The customer provisions and manages virtual machines, storage, and networking, while the provider manages the underlying physical infrastructure. IaaS offers the greatest control and flexibility, but also the greatest security responsibility for the customer.
PaaS provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the underlying infrastructure. The provider manages the operating system, middleware, and runtime environment, while the customer focuses on application code and data.
SaaS delivers a complete software application over the internet. The provider manages everything—infrastructure, platform, application, and data—and the customer accesses the application via a web browser or API. The customer has limited control over the underlying infrastructure and platform.
FaaS is a subset of serverless Computing where the customer writes and deploys individual functions (or microservices) that are triggered by events. The provider automatically scales and manages the runtime environment. The customer is charged based on the number of invocations and execution time.
| Service Model | Abstraction Level | Customer Manages | Provider Manages | Security Focus |
|---|---|---|---|---|
| IaaS | Virtualized infrastructure | OS, middleware, apps, data, IAM | Physical, hypervisor, network | Configuration, patching, network controls |
| PaaS | Platform (OS, runtime) | Apps, data, app-level IAM | Infrastructure, OS, runtime, patching | App code security, secrets, authentication |
| SaaS | Complete application | Users, data classification, config | Everything else | Identity governance, provider trust |
| FaaS / Serverless | Event-driven functions | Function code, deps, secrets, IAM roles | Runtime, scaling, patching | Least privilege, dependency scanning, monitoring |
The NIST definition also identifies four primary deployment models, with a fifth (multi-cloud) being widely recognized in practice. Each model offers different trade-offs between cost, control, security, and compliance.
The public cloud is owned and operated by a third-party cloud service provider (CSP) and is made available to the general public over the internet. Resources are shared across multiple tenants.
The private cloud is dedicated to a single organization. It may be hosted on-premises or by a third-party provider, but the infrastructure is not shared with other organizations.
A hybrid cloud is a combination of public and private clouds, bound together by technology that enables data and application portability (e.g., VPN, Direct Connect, or application integration). Hybrid clouds are common in organizations that want to keep sensitive data on-premises while leveraging the public cloud for scalability and cost efficiency.
A community cloud is shared by several organizations with similar interests or compliance requirements (e.g., a cloud for healthcare providers in a region). The infrastructure may be on-premises or hosted by a third party.
Multi-cloud refers to the use of multiple public cloud providers (e.g., AWS and Azure) to avoid vendor lock-in, increase resilience, or leverage best-of-breed services. This is not a NIST-defined model but is widely adopted in practice.
| Deployment Model | Ownership | Tenancy | Use Case | Security Profile |
|---|---|---|---|---|
| Public Cloud | Third-party CSP | Multi-tenant | General-purpose workloads, startups, web apps | High value; relies on CSP security; customer responsible for configuration |
| Private Cloud | Organization | Single-tenant | Highly sensitive data, regulatory compliance | Full control; organization responsible for entire stack |
| Hybrid Cloud | Organization + CSP | Mixed | Data sensitivity + scalability needs | Requires consistent security policy; secure inter-cloud connectivity |
| Community Cloud | Community | Multi-tenant (community) | Shared compliance and governance (e.g., healthcare) | Governance-dependent; shared responsibility among community |
| Multi-Cloud | Multiple CSPs | Multi-tenant (across providers) | Resilience, avoid lock-in, best-of-breed services | Centralized management required; attack surface expanded |
The core security objectives—confidentiality, integrity, and availability (the CIA triad)—apply to cloud Computing just as they do to traditional IT. However, the cloud context introduces additional nuances:
The shared responsibility model is the cornerstone of cloud security. It defines which security controls are the responsibility of the cloud provider (CSP) and which are the responsibility of the customer. The exact division depends on the service model (IaaS, PaaS, SaaS).
In general, the cloud provider is responsible for the security of the cloud (physical infrastructure, network, hypervisor, and the underlying platform), while the customer is responsible for security in the cloud (data, applications, access management, and configuration).
The shared responsibility model is dynamic: as the service model shifts from IaaS to PaaS to SaaS, the provider's responsibility increases and the customer's decreases. Understanding this model is essential for correctly allocating security resources and ensuring that no security control falls through the cracks.
A cloud security architecture is a comprehensive framework of security controls, policies, and technologies designed to protect cloud environments. While Tutorial 8.3 will dive deep into specific controls, a high-level overview includes:
While cloud providers invest heavily in security, there are inherent assumptions and limitations that customers must be aware of:
Answer the following questions to test your understanding of the tutorial content. Click each "Answer" summary to reveal the solution.
1. On-demand self-service
2. Broad network access
3. Resource pooling
4. Rapid elasticity
5. Measured service
Side-channel attacks, where one tenant may infer information about another tenant by observing shared resource usage patterns (e.g., cache timings, memory access). Also, data co-location and the risk of data leakage across tenants.
Type 1 (bare-metal): Runs directly on hardware with no underlying OS; more
secure and performant; used in cloud data centers (e.g., VMware ESXi, KVM).
Type 2 (hosted): Runs on top of a host OS; less secure and performant; used
for desktop virtualization and development (e.g., VirtualBox).
b) Operating system patching and d) Application code security. The provider is responsible for hypervisor patching (a) and physical data center security (c).
The shared responsibility model defines which security controls are the provider's responsibility and which are the customer's. In IaaS, the customer is responsible for OS, apps, data, and IAM; the provider handles physical and hypervisor security. In PaaS, the provider manages the OS and runtime; the customer focuses on apps and data. In SaaS, the provider manages everything; the customer manages user access and data classification.
Risks include: event injection (malicious data passed via triggers), dependency vulnerabilities (unpatched libraries), overly permissive IAM roles (privilege escalation), and insufficient monitoring (limited visibility into function execution).
Hybrid cloud combines a private cloud (or on-premises) with a public cloud, with integration between them. Multi-cloud uses multiple public cloud providers (e.g., AWS and Azure) but may not include a private cloud component. Hybrid is about public + private; multi-cloud is about multiple publics.
IaC is the practice of managing cloud resources using declarative configuration files (e.g., Terraform, CloudFormation). It is important for security because it enables version control, automated deployment of security controls, auditability, and continuous compliance monitoring. It reduces manual errors and enforces consistent security policies across environments.
1. Identity and Access Management (IAM): authentication, authorization, and
least-privilege access.
2. Data Protection: encryption at rest and in transit, key management.
3. Monitoring and Logging: cloud-native logs, SIEM integration, anomaly detection.
Measured service refers to the metering of resource usage (compute, storage, bandwidth, etc.). Security teams can use usage patterns to detect anomalies: a sudden spike in compute usage might indicate crypto-mining; unexpected outbound traffic might indicate data exfiltration. Metering data provides a rich source of forensic and operational security insights.
Full control over infrastructure, security policies, and physical access. The organization is not sharing resources with other tenants, reducing the risk of side-channel attacks and data co-location issues. It also enables compliance with regulations that mandate physical control over data.
A side-channel attack exploits indirect information (e.g., timing, power consumption, cache usage) to infer sensitive data. In virtualization, an attacker can observe cache timings or memory access patterns of another VM on the same physical host. Spectre and Meltdown are examples of side-channel vulnerabilities that affect speculative execution on modern CPUs.
These practical exercises are designed to reinforce your understanding and apply the concepts covered in this tutorial. Suggested solutions are hidden beneath each exercise.
IaaS:
Provider: physical, hypervisor, network infrastructure.
Customer: OS, apps, data, IAM, network config (security groups).
Control: implement IAM least-privilege policies.
PaaS:
Provider: infrastructure, OS, runtime, patching.
Customer: apps, data, app-level IAM, secrets.
Control: secure application code and use secrets management.
SaaS:
Provider: everything (infra, platform, app, data).
Customer: user management, data classification, config.
Control: enforce MFA and SSO for all users.
FaaS:
Provider: runtime, scaling, patching.
Customer: function code, dependencies, IAM roles, secrets.
Control: assign least-privilege IAM roles to functions.
Hybrid cloud is the most suitable model. The organization can keep patient records (PHI) in a private cloud or on-premises data center to maintain physical control and comply with HIPAA. They can use a public cloud for their web-facing applications, leveraging scalability and cost efficiency. Secure connectivity (e.g., VPN, Direct Connect) between the environments ensures data portability and consistent security policies across both environments.
Risk 1: Dynamic attack surface – Resources are created and destroyed frequently,
making it hard to maintain an accurate asset inventory.
Mitigation: Use Infrastructure as Code (IaC) with automated asset tagging; integrate with CMDB.
Risk 2: Misconfigurations due to automated scaling – New instances may not inherit
correct security configurations.
Mitigation: Use golden images or hardened AMIs; incorporate security scanning into CI/CD pipelines.
Risk 3: Cost explosion from unauthorized scaling – An attacker could trigger
scaling to incur high costs (economic denial of service).
Mitigation: Implement budget alerts and auto-scaling policies with rate limiting; monitor for
anomalous scaling events.
Textual architecture description:
The architecture consists of:
- IAM layer: Centralized identity provider (e.g., AWS IAM) with SSO and MFA
for all users. Roles and policies enforce least-privilege access.
- Data protection: Encryption at rest (AES-256) using a KMS (e.g., AWS KMS)
with customer-managed keys. Encryption in transit via TLS 1.3.
- Network security: VPC with subnets (public and private). Security groups
restrict traffic, and a Web Application Firewall (WAF) protects against application-layer attacks.
- Monitoring and logging: CloudTrail and CloudWatch for operational logs;
integration with SIEM for security analytics. Compliance monitoring via AWS Config.
- Governance: Service Control Policies (SCPs) enforce compliance; regular
vulnerability scanning and patching are automated.
EC2 (IaaS):
Provider: physical security, hypervisor, network infrastructure.
Customer: OS patching, application security, IAM (roles/policies), security groups, data encryption.
RDS (PaaS):
Provider: infrastructure, OS, database engine patching, availability.
Customer: database configuration, user management, data encryption, backups (configurable).
S3 (storage):
Provider: infrastructure, storage hardware, availability, durability.
Customer: bucket policies, IAM permissions, encryption settings, lifecycle policies, versioning.
These homework questions require deeper analysis, research, and synthesis. Use external sources and the course textbook to support your responses.
A strong response would:
– Define each service model and provide examples (AWS EC2, AWS Elastic Beanstalk, Salesforce).
– Discuss the shared responsibility division for each model.
– Analyze real-world incidents: e.g., Capital One (IaaS misconfiguration), Code Spaces (IaaS
compromise), Microsoft (PaaS vulnerability), Salesforce (SaaS misconfiguration).
– Compare the attack surface and risk profiles.
– Provide recommendations: for IaaS, prioritize configuration management and IAM; for PaaS,
focus on application security and secrets management; for SaaS, ensure identity governance
and vendor due diligence.
A strong answer would evaluate each model:
– Public cloud: offers scalability but latency and data sovereignty concerns
may be problematic; may not meet MiFID II requirements for data location.
– Private cloud: provides control over latency and data location, but lacks
scalability and may be costly.
– Hybrid cloud: best compromise: keep low-latency, latency-sensitive components
on-premises or in private cloud, and use public cloud for non-critical workloads (e.g., analytics).
– Multi-cloud: could provide resilience but adds complexity and cost.
Recommendation: hybrid cloud with a strong emphasis on secure inter-connectivity (e.g., AWS
Direct Connect) and consistent security policies. Data sovereignty can be addressed by selecting
a cloud region that complies with MiFID II.
An example response could focus on Spectre (CVE-2017-5753) and
Meltdown (CVE-2017-5754):
– Description: vulnerabilities in speculative execution on modern CPUs that allow unauthorized
reading of memory across process boundaries.
– Affected: all modern CPUs (Intel, AMD, ARM) and hypervisors.
– Impact: a VM can read memory from another VM or the hypervisor, breaching isolation.
– Mitigations: microcode updates from CPU vendors, OS-level patches (KPTI), hypervisor-level
fixes (e.g., disabling speculative execution in certain contexts), and cloud provider response
(e.g., AWS, Azure patched underlying infrastructure). Customers must ensure their guest VMs
are patched and consider migrating to newer CPU generations with hardware mitigations.
A comprehensive plan would include:
– Scope: All AWS services used (EC2, S3, RDS, VPC, IAM, CloudTrail, etc.).
– Areas: IAM (policies, roles, MFA), network (security groups, NACLs, VPC
configuration), data (encryption, key management), logging and monitoring (CloudTrail, CloudWatch,
GuardDuty), compliance (AWS Config, AWS Security Hub).
– Tools: AWS Trusted Advisor, AWS Inspector, AWS Config, third-party CSPM tools
(e.g., Prisma Cloud), manual reviews.
– Reporting: identify risks, prioritize by severity, provide actionable
remediation steps.
– Timeline: 2-week assessment, 1-week reporting, 1-month remediation, and
ongoing monitoring.
A strong paper would:
– Discuss the continued shift toward serverless and FaaS, and the associated security challenges
(event injection, dependency management, ephemeral nature).
– Explore edge Computing and the blurring of cloud and edge; implications for latency, data
sovereignty, and security.
– Analyze the role of AI/ML in both offensive and defensive security; adversarial ML and
automated response.
– Address the quantum Computing threat to cryptography and the need for post-quantum readiness.
– Discuss regulatory trends (e.g., NIS2, GDPR, CCPA) and their impact on cloud adoption.
– Provide recommendations: invest in crypto-agility, adopt Zero Trust, integrate AI/ML into
security operations, and build a culture of continuous learning and adaptation.
Tutorial 8.2 has provided a comprehensive foundation in cloud Computing fundamentals and security principles. We began with the NIST definition of cloud Computing /strong> and explored its five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Each characteristic introduces specific security implications—from the need for automated policy enforcement to the risks of side-channel attacks and the dynamic nature of cloud assets.
We then examined the enabling technologies—virtualization and multi-tenancy—that make cloud Computing possible. We analyzed the security challenges of virtualization, including VM escape, side-channel attacks, and hypervisor vulnerabilities, and discussed the isolation mechanisms that protect tenants in a shared environment. Resource abstraction was presented as a double-edged sword: it provides agility and automation, but also introduces API security risks and configuration complexity.
The cloud service models (IaaS, PaaS, SaaS, FaaS, Serverless) were dissected, with a focus on the division of responsibility between the provider and the customer. The shared responsibility model is the cornerstone of cloud security; understanding it is essential for correctly allocating security resources and ensuring that no control falls through the cracks. We also surveyed the deployment models (public, private, hybrid, multi-cloud, community) and their respective security trade-offs.
Finally, we introduced the fundamentals of cloud security architecture, including IAM, data protection, network security, monitoring, and governance. We acknowledged the inherent assumptions and limitations in cloud security, including trust in the provider and the complexity of regulatory compliance.
This tutorial lays the groundwork for the deeper exploration of cloud security controls and architectures in Tutorial 8.3, and the analysis of cloud threats and incident response in Tutorial 8.4. The concepts covered here—the shared responsibility model, virtualization isolation, service models, and deployment models—will be referenced throughout the rest of Unit 8 and are essential for any cybersecurity professional working with cloud technologies.