Cloud Security Foundations

Introduction

Cloud computing has changed how organisations acquire, operate and protect information technology. Instead of purchasing and maintaining every server, storage device and software platform, a customer can obtain computing capabilities as services over a network. This flexibility creates important security questions: Who controls the infrastructure? Who protects the data? Which security tasks remain the customer’s responsibility? What happens when systems, suppliers and jurisdictions cross organisational boundaries?

Cloud security is not simply traditional information security moved to a remote data centre. Cloud environments are highly programmable, elastic, shared and dependent on management interfaces, application programming interfaces (APIs), identity systems and provider operations. A single configuration error may expose resources at large scale, while a correctly designed cloud architecture can provide strong monitoring, automation and resilience.

This chapter establishes the foundations needed for later study. It explains cloud service and deployment models, essential terminology, the confidentiality–integrity–availability (CIA) triad, defence in depth, least privilege, trust boundaries and the shared-responsibility relationship between cloud providers and customers.

Learning Objectives

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

1. distinguish among infrastructure, platform and software cloud service models;
2. compare public, private, hybrid and community deployment models;
3. explain foundational cloud-security terminology;
4. apply the CIA triad to practical security requirements;
5. describe defence in depth and least privilege;
6. identify trust boundaries in a cloud architecture; and
7. allocate security responsibilities between a provider and a customer.

1. Cloud Computing as a Security Context

Cloud computing is a model for providing convenient, on-demand network access to a shared pool of configurable resources, such as networks, servers, storage, applications and services. These resources can be rapidly provisioned and released with limited direct interaction with the provider.

Four properties are especially important for security:

• On-demand self-service: customers can create resources through portals, APIs or automation. Speed improves, but unauthorised or poorly reviewed changes can also occur quickly.
• Broad network access: services are reachable through networks and therefore require strong identity, endpoint and communications protection.
• Resource pooling: provider resources serve multiple customers. Logical isolation and secure multi-tenancy are essential.
• Rapid elasticity and measured service: resources can scale and usage can be monitored. Security controls must scale with the workload, and records must support accountability.

Cloud security therefore includes technology, people, processes, contracts and governance. It addresses prevention, detection, response, recovery and assurance—not only the blocking of attacks.

2. Cloud Service Models

A service model describes which layer of technology the provider manages and which layer the customer manages. The boundaries vary somewhat among providers, but the following distinctions are widely used.

Infrastructure as a Service (IaaS)

In IaaS, the provider supplies fundamental computing resources such as virtual machines, storage and virtual networks. The customer normally manages the operating system, installed applications, data, identities and many network-security settings.

IaaS offers substantial control and flexibility. It is suitable when an organisation needs customised operating systems or applications. However, the customer must patch systems, harden workloads, configure firewalls and protect credentials. A cloud virtual machine is still a computer that can be compromised.

Platform as a Service (PaaS)

In PaaS, the provider manages the infrastructure and much of the operating-system and runtime environment. The customer deploys applications and manages application code, data, configuration and access controls.

PaaS reduces operational maintenance and can provide secure managed databases, application runtimes and development tools. Its risks include insecure code, excessive permissions, vulnerable dependencies, exposed data stores and misunderstanding of platform configuration.

Software as a Service (SaaS)

In SaaS, the provider delivers a complete application, such as an email, collaboration or customer-management system. The provider manages the application and underlying infrastructure, while the customer remains responsible for users, data classification, access decisions, device security and appropriate configuration.

SaaS does not eliminate customer responsibility. For example, a customer may accidentally share a confidential document publicly, permit a former employee to retain access or approve a malicious application integration.

Comparing service models

The key principle is that moving upward from IaaS to SaaS generally reduces the customer’s infrastructure-management burden, but it does not remove the need for governance, secure configuration or responsible data handling.

3. Cloud Deployment Models

A deployment model describes where resources are hosted, who may use them and how they are administered.

Public cloud

A public cloud is operated by a provider and made available to multiple customers. Customers share physical infrastructure while relying on logical isolation. Advantages include rapid provisioning, broad service choice and economies of scale. Security concerns include dependency on provider controls, misconfiguration, identity compromise, service outages and regulatory requirements concerning data location.

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 premises or elsewhere. A private cloud can provide greater control and customised governance, but it does not automatically provide better security. The organisation still has to design, operate and monitor effective controls.

Hybrid cloud

A hybrid cloud combines distinct cloud environments connected to support data or application portability. For example, an organisation might retain sensitive workloads in a private environment while using public-cloud capacity for analytics. Hybrid arrangements create integration, identity, monitoring and data-transfer boundaries that must be explicitly secured.

Community cloud

A community cloud is shared by organisations with common requirements, such as regulatory, mission or security objectives. It can support sector-specific governance, but participants must agree on responsibilities, assurance evidence, access rules and incident procedures.

Deployment and service models can be combined. An organisation may use public-cloud IaaS, private-cloud PaaS and SaaS simultaneously. Security analysis must therefore examine each service, connection and responsibility boundary rather than assigning one security label to the whole organisation.

4. Essential Security Terminology

• Asset: something valuable that requires protection, including data, systems, identities, services and reputation.
• Threat: a potential cause of harm, such as an attacker, malicious software, insider or natural event.
• Vulnerability: a weakness that can be exploited.
• Risk: the possibility that a threat will exploit a vulnerability and cause harm. Risk assessment normally considers likelihood and impact, although no universal numerical formula is required for every assessment.
• Control: a safeguard that reduces likelihood, impact or both. Controls may be administrative, technical or physical.
• Exposure: the condition of being accessible to a threat, such as an internet-facing management interface.
• Incident: an event that actually or potentially compromises confidentiality, integrity or availability, or violates security policy.
• Authentication: verifying an identity claim.
• Authorisation: deciding what an authenticated identity may do.
• Accountability: associating actions with responsible identities through records and processes.
• Encryption: transforming readable information into protected ciphertext using a cryptographic method.
• Key management: generating, storing, distributing, rotating, restricting and destroying cryptographic keys.
• Multi-tenancy: multiple customers using shared physical or logical resources.
• Identity and access management (IAM): processes and technologies for managing identities, authentication and permissions.
• Configuration drift: gradual divergence between an approved configuration and the actual configuration.
• Logging: recording events; monitoring analyses events and system conditions to identify relevant activity.
• Resilience: the ability to withstand, adapt to and recover from disruption.
• Data residency: the physical or legal location in which data is stored or processed.

These terms support precise communication. For example, authentication proves who a user is; it does not by itself determine what the user is allowed to access.

5. The CIA Triad

The CIA triad is a foundational model for expressing security objectives.

Confidentiality

Confidentiality means preventing unauthorised disclosure of information. Controls include access restrictions, encryption, data-loss prevention, secure disposal and privacy-aware design. A confidentiality failure might involve a public storage bucket, an incorrectly shared document or stolen credentials.

Integrity

Integrity means maintaining the accuracy, completeness and trustworthiness of information and systems. Controls include input validation, authorisation, cryptographic hashes, digital signatures, versioning, change control and audit logs. An integrity failure could alter an invoice, corrupt a software package or modify a medical record.

Availability

Availability means authorised users can access systems and information when required. Controls include redundancy, backups, capacity management, fault tolerance, incident response and denial-of-service protection. Availability requirements must be expressed in business terms: a payroll service may tolerate a short outage, whereas an emergency service may require continuous operation.

Security objectives can conflict. Strong confidentiality controls may make rapid access more difficult; extensive integrity checks may add processing time; high availability may require replicated copies that increase the data-protection burden. Security design is therefore a process of identifying business requirements and selecting proportionate controls.

A useful requirement statement identifies the asset, users, permitted action, condition and security objective. For example: “Only approved payroll administrators may view employee salary records, and every access must be recorded.” This requirement primarily addresses confidentiality and accountability.

6. Defence in Depth

Defence in depth uses multiple, complementary safeguards so that failure of one control does not produce immediate compromise. Layers may include:

1. Governance: policies, risk assessment, contracts and security standards.
2. Physical protection: data-centre access controls, environmental systems and hardware disposal.
3. Perimeter and network controls: segmentation, firewalls, private endpoints and traffic filtering.
4. Identity controls: strong authentication, conditional access and privileged-access management.
5. Workload controls: hardened hosts, secure images, patching and endpoint protection.
6. Application controls: secure coding, dependency management, input validation and testing.
7. Data controls: classification, encryption, backup, retention and access restrictions.
8. Detection and response: logging, alerting, investigation, containment and recovery.

Layers should be independent enough to provide real diversity. For example, two misconfigured firewall rules are not necessarily defence in depth if both depend on the same mistaken assumption. Defence in depth also requires operational testing: an unused alert, an untested backup or an unreviewed access list is a weak control in practice.

7. Least Privilege and Secure Access

Least privilege means granting an identity only the permissions necessary for an authorised task, for only as long as necessary. It applies to human users, administrators, applications, service accounts, automation pipelines and devices.

A practical implementation includes role-based access, separation of duties, just-in-time elevation, multi-factor authentication, short-lived credentials, regular access reviews and removal of unused permissions. Permissions should be granted to groups or roles where practical rather than individually and permanently.

Least privilege is not the same as denying all access. Excessively restrictive permissions can encourage unsafe workarounds, while excessive permissions increase the impact of credential compromise. The objective is a justified, reviewable and proportionate permission set.

Consider a reporting application that only needs to read aggregated sales data. Giving it administrator access to the entire database violates least privilege. A narrowly defined read-only role limits the damage if the application is compromised.

8. Trust Boundaries

A trust boundary is a point or zone where the level of trust, control or security policy changes. Crossing a boundary should trigger authentication, authorisation, validation, encryption or monitoring as appropriate.

Common cloud trust boundaries include:

• a user device to the internet;
• the internet to a cloud API gateway;
• one virtual network segment to another;
• an application to a database;
• a customer account to a provider-controlled management plane;
• one tenant to another tenant’s logically isolated resources;
• a provider service to a third-party SaaS integration; and
• a country or legal jurisdiction to another jurisdiction.

Trust is not binary. A managed database may be more trusted than an unknown internet client, but it still requires authentication and authorisation. “Inside the network” must not be treated as automatically safe. Zero-trust approaches consequently emphasise explicit verification, least privilege and continuous evaluation rather than relying solely on network location.

When analysing a boundary, ask: What crosses it? Who controls each side? What identity is asserted? What data is transferred? Which protocol protects it? What is logged? What happens if the other side is compromised or unavailable?

9. Provider–Customer Shared Responsibility

Cloud security is shared between the provider and customer, but the division changes by service model. Providers generally secure the cloud infrastructure: facilities, physical hardware, core networking and the virtualisation or managed-service layers they operate. Customers generally secure what they place in the cloud: identities, data, applications, configurations and appropriate use.

The division is not a universal fixed table. It depends on the service, contract, architecture and provider documentation. A provider may offer a secure feature, but the customer must enable and configure it correctly.

For example, a provider may be responsible for the security of a storage service’s physical disks, while the customer is responsible for whether a particular storage container is public, which identities can read it and whether the data should be encrypted with customer-controlled keys.

A sound shared-responsibility process should:

1. inventory services and data flows;
2. read provider security documentation and contract terms;
3. identify customer-configurable controls;
4. assign named owners for each control;
5. test configurations continuously;
6. review provider assurance reports; and
7. maintain incident contacts and notification procedures.

Assurance reports and certifications can provide useful evidence, but they do not prove that a customer’s implementation is secure. Compliance is evidence of selected controls against a stated framework; it is not a guarantee of zero risk.

10. Applied Case: A Small Retailer Moving to the Cloud

Background

This illustrative case concerns Northstar Retail, a small retailer moving its online store, inventory data and employee administration to cloud services. It selects public-cloud PaaS for the store, SaaS for email and IaaS for a legacy inventory application.

Problem

During a pilot, a developer grants broad administrative access to the store application. A test database is publicly reachable, and employee accounts do not use multi-factor authentication. The organisation assumes that the provider is responsible for “cloud security.”

Analysis

The provider secures the underlying facilities and managed platform, but Northstar remains responsible for application permissions, database configuration, identities and data handling. The public database is a trust-boundary failure and a confidentiality risk. Broad administrator access violates least privilege. Missing multi-factor authentication increases the likelihood that stolen passwords will lead to compromise.

Availability also matters: the retailer needs the store during business hours, while inventory data requires integrity so that stock levels and orders remain accurate.

Approach and solution

Northstar classifies customer and employee data, removes public network access to the database and permits access only from the application service through a private connection. It creates separate development, test and production accounts. Developers receive limited deployment permissions; production administration requires approval and just-in-time elevation. Multi-factor authentication is enabled for all privileged and workforce accounts.

The retailer enables encryption, centralised logging, alerting for unusual access and automated configuration checks. It tests restoration of backups and documents provider and customer responsibilities in a control register. The SaaS email service is configured to prevent external sharing of sensitive files and to disable accounts promptly when staff leave.

Outcome

The design reduces exposure, limits the effect of stolen credentials and improves the organisation’s ability to detect and recover from incidents. It does not eliminate risk: vulnerabilities in application code, provider outages and social engineering remain possible. Northstar therefore schedules access reviews, patching, incident exercises and supplier reviews.

Learning points

The case demonstrates that service selection changes responsibility but never removes it. Identity, configuration and data governance remain central. Security is strongest when CIA requirements, least privilege, trust boundaries, monitoring and shared responsibility are considered together.

11. Governance, Ethics and Contemporary Practice

Cloud security decisions can affect privacy, equality, safety and public trust. Organisations should collect only necessary data, define lawful purposes, restrict secondary use, retain data for justified periods and provide appropriate transparency. Cross-border processing may create legal obligations concerning privacy, records and government access.

Ethical practice requires more than satisfying minimum law. Security teams should avoid unnecessary surveillance, protect vulnerable users, preserve audit evidence and communicate incidents honestly. Automated security and artificial-intelligence tools can assist with anomaly detection, code analysis and alert triage, but they can also produce false positives, expose sensitive logs or encode biased assumptions. Human review, protected training data and documented decision criteria remain important.

Contemporary cloud practice increasingly includes infrastructure as code, policy as code, continuous control monitoring, confidential-computing capabilities, software-supply-chain security and zero-trust architecture. These approaches improve repeatability and visibility, but automation can also distribute a mistake rapidly. Changes should therefore be peer-reviewed, tested and capable of safe rollback.

12. Practical Foundation Checklist

Before deploying a cloud workload, a certificate-level practitioner should be able to answer:

• What data and services are involved, and how sensitive are they?
• Which service and deployment models are being used?
• Which parties control each trust boundary?
• Who authenticates users and services?
• What permissions are required, and how are they reviewed?
• How are confidentiality, integrity and availability requirements met?
• Which provider and customer controls apply?
• Are logging, alerting, backup and recovery tested?
• Where is data stored and processed?
• How will incidents, supplier changes and account closure be handled?

This checklist is not a substitute for detailed risk assessment, but it prevents common omissions and establishes a disciplined starting point.

Chapter Summary

Cloud security concerns the protection and responsible governance of services, systems, identities and data delivered through cloud environments. IaaS gives customers the greatest infrastructure control; PaaS transfers more platform responsibility to the provider; SaaS supplies a complete application but still requires customer control over users, data and configuration. Public, private, hybrid and community deployment models describe ownership, access and arrangement of environments.

The CIA triad expresses confidentiality, integrity and availability objectives. Defence in depth combines complementary controls across governance, infrastructure, identity, workloads, applications, data and response. Least privilege limits permissions to justified tasks and time periods. Trust boundaries identify points where control or policy changes and where explicit verification is required. Finally, shared responsibility means that provider and customer duties vary by service, contract and configuration; provider assurance cannot replace customer governance.

Key Terms

Asset: Something valuable that requires protection.

Authentication: Verification of an identity claim.

Authorisation: Determination of what an authenticated identity may do.

Availability: Accessibility of authorised systems and information when needed.

Cloud computing: On-demand network access to a shared pool of configurable resources.

Confidentiality: Prevention of unauthorised disclosure.

Control: A safeguard that reduces likelihood, impact or both.

Defence in depth: Use of multiple complementary security layers.

Encryption: Transformation of readable information into protected ciphertext.

Integrity: Accuracy, completeness and trustworthiness of information.

Least privilege: Granting only the permissions necessary for an authorised task.

Multi-tenancy: Use of shared resources by multiple customers.

PaaS: Provider-managed platform on which customers deploy applications.

Risk: Possibility that a threat exploits a vulnerability and causes harm.

SaaS: Provider-delivered complete software application.

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

Trust boundary: Point where trust, control or security policy changes.

Vulnerability: A weakness that can be exploited.

Review Questions

5 Short Answer Questions

1. What is the principal difference between IaaS and SaaS?
2. Define confidentiality, integrity and availability.
3. Why is authentication different from authorisation?
4. What does least privilege mean?
5. Name two common cloud trust boundaries.

5 Long Answer Questions

1. Compare IaaS, PaaS and SaaS, including typical customer security responsibilities.
2. Explain how defence in depth can reduce the consequences of a compromised account.
3. Discuss the advantages and security challenges of hybrid-cloud deployment.
4. Explain why public-cloud use does not transfer all security responsibility to the provider.
5. Describe how a cloud organisation can manage data confidentiality, integrity and availability together.

3 Analytical / Application Questions

1. A company stores customer records in a SaaS platform. An employee makes the records publicly shareable. Identify the relevant trust boundary, CIA objectives and customer controls.
2. Design a least-privilege access approach for a three-person development team deploying a production application.
3. Analyse a proposed architecture in which an internet-facing application connects directly to a production database using an administrator account. Identify weaknesses and propose layered improvements.

Multiple Choice Questions with Answers

Question 1

Which cloud service model usually leaves the customer responsible for the operating system?

A. Infrastructure as a Service (IaaS)

B. Platform as a Service (PaaS)

C. Software as a Service (SaaS)

D. Community cloud

Correct Answer: A. Infrastructure as a Service (IaaS)

Question 2

Which CIA objective is primarily affected when an unauthorised person reads a confidential employee file?

A. Availability

B. Confidentiality

C. Integrity

D. Resilience

Correct Answer: B. Confidentiality

Question 3

Which practice best represents least privilege?

A. Giving every developer permanent administrator access

B. Allowing an application only the read access it needs

C. Sharing one administrator password among a team

D. Disabling all access reviews

Correct Answer: B. Allowing an application only the read access it needs

Question 4

What is a trust boundary?

A. A guaranteed secure network

B. A point where trust or security policy changes

C. A provider’s marketing agreement

D. A backup schedule

Correct Answer: B. A point where trust or security policy changes

Question 5

In a typical cloud arrangement, who is responsible for configuring a customer’s access permissions?

A. Always the hardware manufacturer

B. Usually the customer

C. Only the internet service provider

D. No party

Correct Answer: B. Usually the customer

Question 6

Which deployment model combines distinct cloud environments connected to support data or application portability?

A. Private cloud

B. Community cloud

C. Hybrid cloud

D. Single-tenant SaaS

Correct Answer: C. Hybrid cloud

Question 7

Which control most directly supports integrity?

A. Change control and audit logging

B. Public sharing of all files

C. Removing all backups

D. Disabling authentication

Correct Answer: A. Change control and audit logging

Question 8

A provider secures the physical disks, but the customer leaves a storage container publicly accessible. This illustrates which principle?

A. Security is exclusively the provider’s duty

B. Shared responsibility

C. Availability is irrelevant

D. Encryption eliminates configuration risk

Correct Answer: B. Shared responsibility

Question 9

Which action most directly strengthens privileged-account security?

A. Permanent broad permissions

B. Multi-factor authentication and just-in-time elevation

C. A shared password in a spreadsheet

D. Unmonitored remote access

Correct Answer: B. Multi-factor authentication and just-in-time elevation

Question 10

Which statement about defence in depth is most accurate?

A. It relies on one highly effective control

B. It uses complementary layers so one failure need not cause compromise

C. It removes the need for monitoring

D. It applies only to physical data centres

Correct Answer: B. It uses complementary layers so one failure need not cause compromise