Cloud Computing and Security Foundations

Introduction

Cloud computing has changed how organisations acquire, operate, and secure information technology. Instead of purchasing and maintaining all computing equipment in private facilities, an organisation can obtain computing power, storage, networking, databases, and software as services over a network. This model improves elasticity and speed, but it also changes security responsibilities. A cloud customer may no longer control the physical servers, hypervisors, or data-centre perimeter, yet remains accountable for appropriate access control, data protection, configuration, and regulatory compliance.

Cloud security therefore begins with sound foundations. Security professionals must understand what is being delivered, where it is deployed, which components are virtualised, how cloud-native applications differ from traditional systems, and which party is responsible for each control. This chapter introduces those foundations and establishes the vocabulary needed for later study of risk assessment, identity security, network protection, incident response, and compliance.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the characteristics and benefits of cloud computing.
2. Distinguish the principal cloud service and deployment models.
3. Describe virtual machines, containers, orchestration, and cloud-native systems.
4. Apply the confidentiality, integrity, and availability objectives to cloud environments.
5. Identify common cloud terminology, threat actors, and attack surfaces.
6. Explain the cloud shared responsibility model and its practical implications.
7. Recognise major governance, ethical, and professional issues in cloud security.

1. What Is Cloud Computing?

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources—such as networks, servers, storage, applications, and services—that can be rapidly provisioned and released with minimal management effort or provider interaction. This definition emphasises capability and delivery rather than a particular technology.

Several characteristics distinguish cloud computing from ordinary outsourced hosting:

• On-demand self-service: authorised users can provision resources without manually negotiating with a provider each time.
• Broad network access: services are available through standard network mechanisms and a range of client devices.
• Resource pooling: provider resources serve multiple customers using logical isolation and dynamic allocation.
• Rapid elasticity: capacity can expand or contract in response to demand.
• Measured service: usage is monitored, controlled, and often charged according to consumption.

These properties create both opportunities and risks. Elasticity can improve resilience and reduce idle capacity, but automated scaling can also amplify an attack or generate unexpected costs. Self-service accelerates development, but poorly controlled permissions may allow users or applications to create exposed resources. Multi-tenancy improves efficiency, but customers require assurance that one tenant cannot access another tenant’s data.

Cloud security is the set of administrative, technical, physical, and legal measures used to protect cloud-based information, services, identities, and infrastructure. It includes security within the provider’s platform and security practices performed by the customer. Security is not automatically delivered merely because a system is hosted by a reputable provider.

2. Cloud Service Models

A service model describes the layer of technology supplied by a provider and the amount of operational control retained by the customer.

2.1 Infrastructure as a Service

Infrastructure as a Service (IaaS) provides fundamental computing resources, including virtual machines, virtual networks, block storage, and related infrastructure. The customer generally controls the operating system, installed applications, data, and many network settings. The provider operates the physical facilities, physical hardware, and usually the virtualisation layer.

IaaS resembles operating a data centre with virtual equipment. It provides considerable flexibility, but the customer must patch operating systems, configure firewalls, protect credentials, and harden applications. A cloud virtual machine with an open management port can be as dangerous as a poorly secured physical server.

2.2 Platform as a Service

Platform as a Service (PaaS) provides a managed application platform, such as a runtime, database service, or development environment. The provider manages more of the operating system and platform components. The customer concentrates on application code, data, identities, and configuration.

PaaS can reduce patching responsibilities and accelerate development. However, it introduces platform dependency, configuration risks, and the need to understand provider-specific security controls. Application vulnerabilities, excessive permissions, insecure secrets, and weak input validation remain customer concerns.

2.3 Software as a Service

Software as a Service (SaaS) delivers a complete application through a browser, mobile client, or application interface. The provider normally manages the application, platform, operating system, and physical infrastructure. The customer remains responsible for matters such as account lifecycle, access permissions, data classification, secure use, and organisational policy.

SaaS security failures frequently arise from misconfigured sharing, weak authentication, unmanaged third-party integrations, inadequate retention settings, or users uploading sensitive information without approval. A provider’s application security does not replace customer identity governance.

2.4 Event-Driven and Serverless Services

In serverless computing, the customer submits functions or uses managed services while the provider manages server allocation and much of the runtime infrastructure. “Serverless” does not mean that servers are absent; it means that their provisioning and operation are abstracted from the customer.

Security concerns include excessive function permissions, insecure event inputs, dependency vulnerabilities, data leakage through logs, and difficulty tracing short-lived executions. The model can reduce infrastructure administration while increasing the importance of identity, application, and event-flow controls.

Service Model Comparison

The boundaries are not identical across providers. A service catalogue and provider documentation must be examined rather than relying only on a model label.

3. Cloud Deployment Models

A deployment model describes who owns, operates, and has access to the cloud environment.

Public Cloud

A public cloud is available to multiple customers through a provider’s shared infrastructure. Logical isolation separates tenants, while the provider manages physical facilities. Public cloud offers extensive scalability and a broad range of services, but customers must manage exposure, permissions, data location, and provider dependency.

Private Cloud

A private cloud is dedicated to one organisation. It may be operated by the organisation or by a third party and may exist on or off the organisation’s premises. Private cloud can support specialised compliance or control requirements, but it does not automatically provide better security. Poorly managed private infrastructure remains vulnerable.

Community Cloud

A community cloud is shared by organisations with common requirements, such as regulatory, mission, or operational needs. Governance must specify who may use the environment, how controls are funded, and how accountability is divided.

Hybrid Cloud

A hybrid cloud combines two or more distinct cloud or on-premises environments that remain separate but are connected to support data or application portability. Hybrid arrangements can support gradual migration and sensitive-data placement, but interconnection creates additional identity, networking, monitoring, and data-transfer risks.

Multi-Cloud

Multi-cloud uses services from multiple cloud providers. It may reduce dependence on one provider or allow an organisation to select specialised services. It also increases complexity in identity federation, logging, policy enforcement, skills, incident response, and data movement. Multi-cloud is not automatically more resilient; resilience requires tested architectures and operational coordination.

4. Virtualisation and Isolation

Virtualisation abstracts physical computing resources so that multiple logical systems can operate on one physical host. A hypervisor manages virtual machines (VMs), allocating processor time, memory, storage, and network connectivity. A VM includes a guest operating system and applications, while the host provides the underlying physical resources.

Virtualisation supports consolidation, rapid provisioning, snapshots, migration, and elasticity. It also creates security dependencies. A vulnerability in a hypervisor or management plane could affect multiple tenants. Incorrect virtual-network rules may expose several VMs, and an image containing embedded credentials can reproduce the same weakness across many instances.

Isolation is a security property, not an absolute assumption. Providers use hardware controls, hypervisor boundaries, identity systems, network segmentation, and monitoring to separate customers. Customers should still minimise trust, apply patches, restrict management interfaces, and use approved images.

A virtual machine image is a template containing an operating system and software configuration. Images should be sourced from trusted repositories, scanned for vulnerabilities and secrets, versioned, signed where supported, and removed or replaced when obsolete. Snapshots and backups may contain sensitive data and therefore require equivalent protection.

5. Containers and Orchestration

A container packages an application and its dependencies while sharing the host operating-system kernel. Unlike a VM, a container normally does not contain a complete guest operating system. Containers are lightweight and start quickly, making them useful for continuous delivery and elastic workloads.

Containers are not inherently secure. Their security depends on image provenance, dependency management, runtime configuration, kernel protection, secrets handling, and access control. A process running as root inside a container, an exposed container socket, or an image containing malware can create serious risk.

A container image should be minimal, regularly rebuilt, scanned, and stored in a controlled registry. Images should avoid embedded passwords and should use immutable version identifiers where practical. Runtime privileges should be restricted, writable filesystems minimised, and network communication limited.

A container orchestrator schedules and manages containers across a cluster. Kubernetes is a prominent example. Orchestration introduces objects such as clusters, nodes, workloads, services, namespaces, roles, and secrets. The control plane is highly sensitive: compromise may permit deployment of malicious workloads or access to cluster resources. Role-based access control, admission policies, network policies, audit logs, and secure node configuration are therefore essential.

6. Cloud-Native Systems

A cloud-native system is designed to exploit cloud characteristics such as automation, elasticity, managed services, distributed operation, and rapid change. Cloud-native architecture commonly uses microservices, APIs, containers, orchestration, infrastructure as code, automated pipelines, and observable services.

Microservices divide an application into independently deployable services. This can improve team autonomy and scaling, but it expands the number of interfaces and trust relationships. Each service may have its own identity, dependencies, data stores, and logging requirements. An attacker who compromises one service may attempt lateral movement to others.

Infrastructure as Code (IaC) expresses infrastructure configuration in machine-readable files. IaC improves repeatability and reviewability, but insecure templates can deploy vulnerabilities at scale. IaC should undergo code review, secret scanning, policy checks, version control, and controlled deployment.

A CI/CD pipeline automatically builds, tests, scans, and deploys software. Pipeline credentials and build systems are high-value targets. Security should be integrated throughout the software lifecycle, including dependency scanning, static and dynamic testing, artifact integrity, approval controls, and post-deployment monitoring.

Cloud-native security is consequently distributed. There may be no single perimeter. Protection must operate across identities, workloads, APIs, data, networks, code repositories, pipelines, and management planes. This approach is often described as zero trust: access is not granted merely because a user or workload is inside a network; decisions should consider identity, device or workload context, resource, policy, and risk.

7. Security Objectives and Core Terminology

The traditional CIA triad provides a foundation for security objectives.

• Confidentiality means preventing unauthorised disclosure of information.
• Integrity means protecting information and systems against unauthorised alteration or destruction.
• Availability means ensuring authorised users can access systems and information when required.

Cloud examples include encrypting storage to support confidentiality, using signed artifacts and audit trails to support integrity, and designing across failure zones with tested recovery procedures to support availability. Security objectives may conflict. Strong encryption can complicate recovery if keys are lost; aggressive availability measures can increase cost; extensive logging can create privacy and retention obligations.

Important related terms include:

• Authentication: verifying an identity or claimed origin.
• Authorisation: determining what an authenticated identity may do.
• Accounting or auditing: recording actions and events for review.
• Identity and Access Management (IAM): administration of users, workloads, roles, credentials, and permissions.
• Least privilege: granting only the access necessary for an approved task and duration.
• Non-repudiation: evidence supporting the origin and integrity of an action so that it cannot credibly be denied; in practice, it depends on trustworthy identity, records, and controls.
• Encryption at rest: protection of stored data.
• Encryption in transit: protection of data moving between systems.
• Key management: generation, storage, use, rotation, recovery, and destruction of cryptographic keys.
• Vulnerability: a weakness that can be exploited.
• Threat: a circumstance or actor capable of causing harm.
• Risk: the potential for harm resulting from uncertainty, commonly considered in relation to likelihood and impact.
• Control: a safeguard that modifies risk.
• Exposure: the condition of being accessible to a threat or unintended party.
• Misconfiguration: an insecure or incorrect setting, such as public storage or excessive permissions.
• Security event: an observable occurrence relevant to security.
• Security incident: an event or series of events that compromises or threatens confidentiality, integrity, or availability and requires response.

Risk is not calculated by a universal equation. A qualitative assessment may classify likelihood and impact as low, medium, or high. Quantitative approaches sometimes estimate annualised loss, but results depend on reliable assumptions and data. Organisations should not treat a numerical score as a substitute for professional judgement.

8. Threat Actors and Attack Surfaces

A threat actor is an individual, group, organisation, or process capable of causing harm. Relevant actors include:

• Cybercriminals, who seek financial gain through ransomware, fraud, credential theft, or data extortion.
• Nation-state or state-sponsored groups, which may pursue espionage, disruption, influence, or strategic advantage.
• Insiders, including malicious employees, contractors, or careless authorised users.
• Hacktivists, who target organisations for ideological or political reasons.
• Competitors or industrial spies, who seek confidential business or technical information.
• Supply-chain attackers, who compromise software, dependencies, providers, or managed-service relationships.
• Automated scanners and opportunistic attackers, who exploit exposed services at scale.

An attack surface is the collection of points through which an attacker may attempt access, influence, or disruption. Cloud attack surfaces include:

1. Identity surfaces: passwords, tokens, API keys, federated identities, service accounts, and privileged roles.
2. Management planes: provider consoles, command-line tools, APIs, and automation pipelines.
3. Data stores: object storage, databases, snapshots, backups, logs, and caches.
4. Network interfaces: public endpoints, load balancers, remote administration ports, DNS, and hybrid connections.
5. Application and API interfaces: authentication flows, input handling, authorisation logic, and exposed service methods.
6. Workloads: VMs, containers, serverless functions, and operating systems.
7. Software supply chains: source repositories, dependencies, images, build servers, and deployment artifacts.
8. Human and governance processes: approvals, separation of duties, incident procedures, vendor oversight, and training.

A useful security review identifies assets, owners, trust boundaries, entry points, dependencies, possible abuse cases, and controls. Threat modelling methods such as STRIDE can help teams systematically consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The method is a structured aid, not a guarantee that every threat has been found.

9. The Shared Responsibility Model

The shared responsibility model states that cloud security responsibilities are divided between the provider and the customer. The provider is responsible for security of the cloud, while the customer is responsible for security in the cloud. The exact boundary varies by service.

The provider typically manages data-centre buildings, physical access, physical networks, hardware, and core platform components. The customer typically manages data classification, user identities, permissions, application security, secure configuration, and appropriate use. In IaaS, the customer usually manages the guest operating system. In PaaS, the provider manages more of the platform. In SaaS, the provider manages the application, but the customer still manages users, access, data, and settings.

Responsibilities may be shared. The provider may offer encryption, logging, backup, and security monitoring capabilities, while the customer must enable, configure, review, and use them correctly. A provider can supply a secure storage service, but a customer may still make a bucket public.

A practical responsibility matrix should identify each asset or control, the responsible party, evidence of implementation, and review frequency. Responsibility should be confirmed in contracts, service descriptions, security documentation, and audit reports. “The provider is responsible” is not an adequate risk treatment unless the scope and evidence are clear.

10. Applied Case: A Misconfigured Cloud Application

The following is an illustrative case, not a report of a particular organisation.

Background

A growing retail company migrates its customer analytics application to a public cloud. The application uses object storage for uploaded reports, a managed database, container workloads, and a CI/CD pipeline. Developers are permitted to create resources rapidly to meet business deadlines.

Problem

A storage repository containing customer reports is accidentally configured for public access. In addition, a deployment service account has broad administrative permissions, and a container image contains an outdated library. Monitoring records API activity but does not alert on public exposure or unusual data downloads.

Analysis

The central failure is not a lack of cloud technology; it is inadequate governance and control design. The attack surface includes the storage policy, service-account credentials, the container image, the deployment pipeline, and incomplete monitoring. Potential impacts include confidentiality loss, regulatory consequences, customer harm, reputational damage, and unauthorised changes to the environment.

The shared responsibility model clarifies the issue. The provider operates the storage service securely, but the customer controls the repository’s access policy and data classification. The provider may offer vulnerability scanning and security alerts, but the customer must enable and act on them.

Approach and Solution

The company applies the following measures:

1. Classify customer reports and prohibit public access through organisation-wide policy.
2. Require private-by-default storage and automated policy checks before deployment.
3. Replace the broad service account with separate roles using least privilege.
4. Move secrets to a managed secrets service rather than source code or images.
5. Rebuild the container image with current dependencies and scan it in the pipeline.
6. Enable alerts for public exposure, unusual downloads, privilege changes, and anomalous authentication.
7. Centralise immutable audit logs and establish an incident-response procedure.
8. Test restoration, access reviews, and the effectiveness of preventive policies.

Outcome

The organisation prevents the insecure configuration from being redeployed, reduces the permissions available to compromised credentials, and improves detection. It also establishes an approval process for high-risk changes without eliminating developer self-service.

Learning Points

Cloud security is a socio-technical discipline. Secure provider infrastructure cannot compensate for excessive permissions, insecure code, poor configuration, or absent monitoring. Preventive controls, detective controls, response capability, and governance must operate together.

11. Governance, Ethics, and Regulation

Cloud decisions affect privacy, safety, fairness, and organisational accountability. Data protection laws may regulate personal data processing, international transfers, retention, breach notification, and individual rights. Sector requirements may impose stronger controls for health, finance, education, or critical infrastructure. Compliance is not identical to security: compliance establishes required obligations, while security manages broader technical and operational risk.

Organisations should identify data owners, retention periods, lawful processing requirements, geographic constraints, subcontractors, and exit arrangements. They should understand how provider logs, support access, backups, and metadata are handled. Contracts should address incident notification, audit rights, service availability, deletion, portability, and responsibility boundaries.

Ethically, cloud professionals should minimise unnecessary collection, protect vulnerable people, avoid discriminatory automated decisions, and communicate limitations honestly. Monitoring must be proportionate and governed; security surveillance can itself threaten privacy. Artificial intelligence services create additional concerns involving sensitive training data, model leakage, prompt injection, insecure plugins, opaque decisions, and uncertain data residency. AI should be treated as another workload and supply-chain dependency requiring identity, data, logging, testing, and human oversight.

12. Best Practices for Foundational Cloud Security

A sound baseline includes:

• Establish a clear account or tenant structure and separate production from development.
• Use strong authentication, preferably phishing-resistant multi-factor authentication for privileged access.
• Apply least privilege, role separation, and periodic access reviews.
• Deny public access by default and restrict network paths.
• Encrypt sensitive data in transit and at rest, with carefully managed keys.
• Store secrets in approved secret-management systems and rotate them.
• Use hardened, current images and patch workloads and dependencies.
• Treat IaC and CI/CD systems as production security assets.
• Enable central logging, time synchronisation, alerting, and retention appropriate to risk.
• Back up important data and test restoration; a backup that cannot be restored is not dependable resilience.
• Conduct threat modelling, vulnerability management, configuration assessment, and incident exercises.
• Document the shared responsibility boundary and maintain evidence for governance and audits.
• Plan portability, provider outage response, and secure service termination.

Chapter Summary

Cloud computing delivers configurable technology resources through on-demand, network-accessible services. Its principal service models are IaaS, PaaS, SaaS, and serverless, while deployment models include public, private, community, hybrid, and multi-cloud. Virtualisation provides logical machines through a hypervisor; containers package applications while sharing a kernel; orchestration manages distributed workloads; and cloud-native systems use automation, APIs, microservices, and managed services.

Confidentiality, integrity, and availability remain central security objectives, but cloud environments expand the number of identities, interfaces, services, and dependencies that must be protected. Threat actors may exploit management planes, data stores, APIs, workloads, supply chains, or human processes. The shared responsibility model divides duties between provider and customer, but customers must verify exactly what they are responsible for and configure available protections correctly. Effective cloud security combines least privilege, secure configuration, encryption, monitoring, resilience, governance, ethical data handling, and tested response.

Key Terms

Cloud computing: On-demand network access to pooled, configurable computing resources.

IaaS: A service model providing virtualised infrastructure resources.

PaaS: A service model providing a managed application platform.

SaaS: A complete provider-managed software application delivered as a service.

Public cloud: Cloud infrastructure shared among multiple customers through a provider.

Private cloud: Cloud infrastructure dedicated to one organisation.

Hybrid cloud: Connected use of distinct cloud or on-premises environments.

Virtualisation: Abstraction of physical resources into logical computing environments.

Hypervisor: Software or firmware that manages virtual machines.

Container: A packaged application environment that commonly shares the host kernel.

Orchestrator: Software that schedules and manages containers or workloads.

Cloud-native: Designed to exploit elasticity, automation, distributed services, and managed cloud capabilities.

IAM: Processes and technologies for managing identities and access.

Least privilege: Granting only the access required for an authorised task.

Attack surface: Points through which attack or unintended influence may occur.

Vulnerability: A weakness that may be exploited.

Threat actor: A person, group, organisation, or process capable of causing harm.

Shared responsibility model: Division of cloud security duties between provider and customer.

Infrastructure as Code: Machine-readable definition and management of infrastructure.

Zero trust: A security approach that does not grant implicit trust based solely on network location.

Review Questions

5 Short Answer Questions

1. What are the five essential characteristics commonly associated with cloud computing?
2. Distinguish IaaS from PaaS.
3. Why are containers not automatically secure?
4. Define confidentiality, integrity, and availability.
5. What does the shared responsibility model mean?

5 Long Answer Questions

1. Compare public, private, hybrid, and multi-cloud deployment models, including security advantages and limitations.
2. Explain how virtual machines, containers, and orchestration differ and identify important security controls for each.
3. Discuss how cloud-native architecture changes the traditional network-perimeter approach to security.
4. Explain the major attack surfaces in a cloud environment and how least privilege reduces exposure.
5. Discuss governance, privacy, and ethical issues that an organisation should address before migrating sensitive data to the cloud.

3 Analytical / Application Questions

1. An organisation discovers that an object-storage repository containing personal data is publicly accessible. Analyse the likely causes, responsibilities, impacts, and immediate and long-term controls.
2. A development team requests administrator permissions for a deployment account because it wants faster releases. Design a safer alternative using IAM, automation, approval, monitoring, and emergency-access principles.
3. Compare the security implications of deploying an application on IaaS virtual machines, a managed PaaS platform, and a container-orchestration service. Recommend a model for a small organisation with limited security staff and justify your decision.

Multiple Choice Questions with Answers

Question 1

Which characteristic allows cloud resources to expand or contract in response to demand?

A. Measured service

B. Rapid elasticity

C. Resource pooling

D. Broad network access

Correct Answer: B. Rapid elasticity

Question 2

In a typical IaaS arrangement, which responsibility normally remains with the customer?

A. Maintaining the provider’s physical data centre

B. Repairing physical host hardware

C. Patching the guest operating system

D. Managing the hypervisor code

Correct Answer: C. Patching the guest operating system

Question 3

What is the main difference between a container and a virtual machine?

A. A container normally shares the host kernel, while a VM includes a guest operating system

B. A VM cannot run applications

C. A container always provides stronger isolation than a VM

D. A VM does not require computing hardware

Correct Answer: A. A container normally shares the host kernel, while a VM includes a guest operating system

Question 4

Which security objective is primarily concerned with preventing unauthorised alteration of data?

A. Confidentiality

B. Availability

C. Integrity

D. Portability

Correct Answer: C. Integrity

Question 5

Which item is an example of a cloud identity attack surface?

A. A provider’s office furniture

B. An API key

C. A cooling system

D. A physical loading bay

Correct Answer: B. An API key

Question 6

What does least privilege require?

A. Every administrator should have full access to all systems

B. Users should receive only the access necessary for authorised tasks

C. Access should never be reviewed after it is granted

D. All services should use one shared account

Correct Answer: B. Users should receive only the access necessary for authorised tasks

Question 7

Under the shared responsibility model, which task is generally a customer responsibility even when using SaaS?

A. Operating the provider’s physical servers

B. Repairing the provider’s network switches

C. Managing user access and data-sharing settings

D. Patching the provider’s application code

Correct Answer: C. Managing user access and data-sharing settings

Question 8

Why is a cloud management plane especially sensitive?

A. It usually contains no authentication mechanisms

B. It can control resources, permissions, and configurations

C. It is physically disconnected from all workloads

D. It is used only for billing and cannot change systems

Correct Answer: B. It can control resources, permissions, and configurations

Question 9

Which practice best reduces the risk of secrets being exposed in container deployments?

A. Embedding passwords in container images

B. Using one permanent password for every workload

C. Storing secrets in an approved secrets-management service

D. Publishing images without version identifiers

Correct Answer: C. Storing secrets in an approved secrets-management service

Question 10

Which statement best describes zero trust?

A. Users inside the corporate network are automatically trusted

B. All internet traffic is blocked permanently

C. Access decisions consider identity, context, resource, and policy rather than network location alone

D. Only physical security controls are required

Correct Answer: C. Access decisions consider identity, context, resource, and policy rather than network location alone