Cloud Computing and Shared-Responsibility Security

Introduction and Context

Cloud computing has changed how organisations acquire, operate and secure information technology. Instead of purchasing all servers, storage systems and networking equipment, an organisation can obtain computing resources as services over a network. Capacity can be increased or reduced rapidly, and users can access services from many locations and devices.

Cloud adoption, however, does not remove security responsibilities. It changes how those responsibilities are divided among the cloud provider, the customer, software suppliers, administrators and end users. A provider may secure a data centre and the physical infrastructure, while the customer remains responsible for identity management, data classification and secure configuration. Many serious cloud incidents result not from a failure of the provider’s physical security, but from exposed storage, excessive privileges, stolen credentials or vulnerable customer applications.

This chapter explains cloud deployment models, service models, shared responsibility, cloud risk assessment and secure architecture. It also considers governance, compliance, resilience and practical security operations.

Learning Objectives

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

1. Distinguish public, private, hybrid and multi-cloud deployment models.
2. Explain IaaS, PaaS, SaaS and serverless computing.
3. Apply the shared-responsibility model to common cloud services.
4. Identify cloud-specific threats, risks and control requirements.
5. Design a secure, resilient and governable cloud architecture.
6. Evaluate cloud decisions using practical risk and business criteria.

1. Foundations of Cloud Computing

A widely used definition describes cloud computing as on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with limited management effort. The important characteristics are:

• On-demand self-service: authorised users can provision resources without manual intervention by the provider.
• Broad network access: services are available through standard network mechanisms.
• Resource pooling: provider resources serve multiple customers, with logical isolation between them.
• Rapid elasticity: capacity can expand or contract as demand changes.
• Measured service: use is monitored and commonly associated with consumption-based billing.

These characteristics create both advantages and risks. Elasticity improves availability and can reduce unused capacity, but it may also produce uncontrolled expenditure or rapidly expand an attack surface. Self-service accelerates innovation, but poorly governed self-service can create insecure resources. Multi-tenancy can improve efficiency, while isolation failures would have serious consequences.

Cloud security therefore combines traditional cybersecurity with infrastructure abstraction, automation, identity-centric control and supplier governance.

2. Cloud Deployment Models

A deployment model describes who owns, operates and accesses the cloud environment.

Public Cloud

A public cloud is operated by a third-party provider and delivers resources to multiple customers. Customers normally share underlying physical infrastructure while remaining logically isolated. Examples include public compute, storage, databases and hosted business applications.

Strengths include rapid provisioning, global reach, extensive managed services and reduced capital expenditure. Risks include dependence on provider availability, configuration errors, data-residency concerns, service lock-in and less direct control over hardware.

Public cloud is suitable for many web applications, development environments, analytics workloads and commercial software services, provided that identity, configuration and data controls are properly designed.

Private Cloud

A private cloud is dedicated to one organisation. It may be located in the organisation’s own data centre or hosted by a specialist provider. Private cloud can provide greater control, customisation and predictable placement of sensitive workloads.

It generally requires more investment, specialist skills and operational responsibility than public cloud. A private environment is not automatically secure: weak patching, poor segmentation or excessive administrative access can create major vulnerabilities.

Hybrid Cloud

A hybrid cloud combines private and public cloud environments with mechanisms for data, identity or workload integration. An organisation might retain regulated records in a private environment while using public cloud resources for customer-facing elasticity.

Hybrid designs can support gradual migration and workload placement based on sensitivity, performance or regulatory requirements. They also introduce integration complexity. Insecure connections, inconsistent identity policies and unclear ownership across environments are common weaknesses.

Multi-Cloud

Multi-cloud means using services from two or more cloud providers. It may be intentional, for example to select the strongest service from each provider, or accidental, when departments independently adopt different platforms.

Multi-cloud can reduce dependence on one provider and support geographic or functional requirements. However, it creates differences in terminology, logging, identity, networking, security controls and incident response. It should not be confused with hybrid cloud: hybrid refers to combining different deployment environments, whereas multi-cloud refers specifically to multiple cloud providers.

3. Cloud Service Models

A service model describes the layer managed by the provider and the layer managed by the customer.

Infrastructure as a Service (IaaS)

IaaS supplies virtual machines, networks, storage and related infrastructure. The provider manages physical facilities, hardware and usually the virtualisation layer. The customer manages the operating system, installed applications, identity configuration, data and many network controls.

IaaS offers substantial flexibility but leaves the customer with significant security duties. Examples of customer failures include unpatched virtual machines, publicly exposed management ports, insecure images and excessive administrator permissions.

Platform as a Service (PaaS)

PaaS supplies a managed application platform, such as a runtime, managed database or application-development environment. The provider manages more of the operating system and platform stack. The customer normally remains responsible for application code, data, identities, secrets and secure use of the platform.

PaaS can reduce patching work and encourage standardisation, but developers may misunderstand platform defaults or assume that managed services automatically protect application logic.

Software as a Service (SaaS)

SaaS delivers a complete application, such as email, collaboration, customer relationship management or accounting software. The provider manages the application and underlying infrastructure. The customer remains responsible for users, access policies, data governance, acceptable use, integrations and often tenant-level configuration.

SaaS security failures frequently involve weak authentication, oversharing, unmanaged third-party applications, insecure exports and inadequate offboarding.

Serverless and Function as a Service

Serverless computing allows customers to execute functions or workloads without managing servers directly. The provider allocates execution infrastructure, scales it and commonly charges according to invocation or execution characteristics. The customer still controls code, dependencies, triggers, permissions, data and secrets.

Serverless does not mean “without security responsibility.” Risks include overly broad function permissions, vulnerable dependencies, injection through event data, insecure API gateways, excessive execution privileges and inadequate monitoring. Short-lived functions can also complicate forensic investigation.

4. The Shared-Responsibility Model

Shared responsibility is a division of security duties between provider and customer. The exact boundary differs by provider and service, so organisations must consult contractual documentation, service descriptions and security responsibility matrices.

The provider generally secures of the cloud: physical buildings, power, cooling, hardware, core networking and the managed components included in the service. The customer generally secures in the cloud: data, identities, account use, configurations, applications and workload-specific controls.

The boundary moves upward as the service becomes more managed. In IaaS, the customer manages more of the stack; in SaaS, the provider manages more technical layers, but the customer still controls business use and data access.

Figure: The responsibility boundary changes with the service model, but customer governance remains essential.

A responsibility matrix should identify, for each control, the accountable party, the implementing party, evidence required and review frequency. “The provider handles security” is not an adequate control statement.

5. Cloud Threats and Risk Assessment

Important cloud threats include:

• compromised administrator or developer credentials;
• excessive permissions and privilege escalation;
• publicly exposed storage, databases or management interfaces;
• insecure application programming interfaces (APIs);
• vulnerable images, libraries and container components;
• poor tenant separation or insecure service configuration;
• malicious insiders or compromised suppliers;
• data loss, ransomware and accidental deletion;
• denial-of-service attacks;
• inadequate logging and delayed detection;
• shadow cloud use and unapproved services;
• regulatory breaches caused by location, retention or access practices.

Risk assessment should be systematic rather than based only on provider reputation. A practical process is:

1. Identify assets: data, applications, identities, APIs, keys and business processes.
2. Classify information: for example, public, internal, confidential or highly restricted.
3. Identify threats and vulnerabilities: consider technical, human, supplier and environmental causes.
4. Estimate likelihood and impact: use a documented scale or quantitative method.
5. Select treatments: reduce, avoid, transfer or accept the risk.
6. Assign ownership: name the person or function responsible.
7. Monitor residual risk: reassess after architectural or business changes.

A simple qualitative risk model is often useful:

Likelihood and impact are ordinal scores, such as 1 to 5, rather than physical measurements. The multiplication provides a prioritisation aid, not an objective probability. An organisation must define score meanings, thresholds and escalation rules. A low numerical score does not justify ignoring a legal obligation or a catastrophic but unlikely event.

For a more quantitative estimate, annualised loss expectancy may be expressed as:

Here, SLE is the single-loss expectancy in currency units, and ARO is the annual rate of occurrence. This model assumes that loss per event and event frequency can be estimated meaningfully. Estimates are uncertain and should be accompanied by ranges and qualitative judgement.

6. Secure Cloud Architecture

Identity-Centred Security

Identity is the primary control plane in cloud environments. Apply least privilege, strong authentication and separation of duties. Recommended controls include:

• central identity federation where practical;
• multi-factor authentication, especially for privileged access;
• role-based or attribute-based access control;
• just-in-time elevation for administrative tasks;
• separate administrative accounts;
• regular entitlement review;
• immediate removal of leavers and dormant accounts;
• short-lived credentials and managed identities instead of embedded keys.

Least privilege means granting only the permissions necessary for an approved task, for the required duration. It must apply to human users, applications, functions, service accounts and automated pipelines.

Network and Workload Protection

Use segmentation to limit unnecessary communication between workloads. Public-facing services should be separated from internal systems. Administrative interfaces should not be directly exposed to the public internet unless a documented, strongly controlled design requires it.

Security groups, network access controls, private endpoints, web application firewalls and denial-of-service protections can reduce exposure. Network controls are not substitutes for identity and application security; a permitted request may still be malicious.

Data Protection

Data protection includes classification, minimisation, encryption, key management, retention and secure disposal. Encryption in transit protects communications over networks, while encryption at rest protects stored data if storage media or snapshots are exposed. Encryption does not prevent an authorised but malicious application from reading decrypted data.

Key management should define ownership, rotation, access, backup, recovery and separation of duties. Secrets should be stored in a dedicated secrets-management service rather than source code, images, spreadsheets or ordinary configuration files.

Secure Development and Configuration

Infrastructure as code can make cloud configuration repeatable, reviewable and testable. Secure pipelines should include code review, dependency scanning, secret detection, policy checks and controlled deployment. Images and dependencies should be sourced from trusted repositories, scanned and updated.

Configuration management should detect public exposure, unencrypted storage, excessive permissions, missing logs and unsupported software. Baselines must be tailored to business requirements; blindly applying a template can break services or create a false sense of security.

Logging, Monitoring and Detection

Collect authentication events, administrative actions, configuration changes, network flows, application logs and data-access events where appropriate. Logs should be time-synchronised, protected from alteration, retained according to policy and monitored for meaningful signals.

Examples of useful detections include impossible travel, unusual privilege changes, mass data access, disabled logging, new public endpoints and abnormal function invocation. Monitoring without an incident response process produces information but not necessarily security.

Resilience and Recovery

Availability requires more than choosing a large provider. Design for component failure, service limits, regional disruption, credential compromise and accidental deletion. Important measures include independent backups, tested restoration, redundancy, documented recovery priorities and separation between production and backup administration.

Two common recovery metrics are:

• Recovery time objective (RTO): the maximum acceptable time to restore a service.
• Recovery point objective (RPO): the maximum acceptable amount of data loss measured in time.

For example, an RPO of 15 minutes means that the organisation aims to lose no more than approximately 15 minutes of transactional data under the stated recovery design. Neither RTO nor RPO is guaranteed merely because a service is hosted in the cloud; they must be engineered and tested.

7. Governance, Compliance and Ethics

Cloud governance establishes who may acquire services, what controls are mandatory, how exceptions are approved and how performance is measured. A governance programme should address:

• approved providers and service catalogues;
• data classification and residency;
• contract, audit and breach-notification requirements;
• identity and privileged-access standards;
• security architecture review;
• supplier and subprocessor risk;
• financial controls and resource tagging;
• vulnerability, patch and incident-management processes;
• retention, deletion and legal hold requirements.

Regulatory duties depend on jurisdiction and sector. Privacy laws may regulate processing purpose, international transfers, individual rights and breach response. Financial, healthcare and public-sector rules may impose additional requirements. Compliance certification can provide evidence, but it does not prove that a customer’s tenant is correctly configured.

Ethically, organisations should consider surveillance, meaningful consent, data minimisation, algorithmic discrimination and the effect of outages on vulnerable users. Cloud providers and customers should avoid collecting or retaining data merely because storage is inexpensive.

8. Applied Case: Northstar Online Services

This is an illustrative case. Northstar, a medium-sized education provider, plans to move its learning platform to a public cloud. The platform contains student records, assessment results and payment information. The organisation wants rapid scaling during examination periods and lower infrastructure-maintenance costs.

Background and Problem

The initial design places the application, database and administrative interface on public addresses. Developers share a powerful cloud account, database backups are stored in the same account as production, and application secrets are kept in a configuration file. The provider is assumed to be responsible for security.

A risk review identifies four high-priority risks: credential compromise, accidental public exposure, ransomware or destructive deletion, and unauthorised access to sensitive records.

Analysis

The service is primarily IaaS with a managed database, so Northstar remains responsible for operating-system patching, identities, application security, data protection and configuration. The provider remains responsible for physical infrastructure and the managed components included in the service. The initial design has a confused responsibility boundary and excessive trust in network location.

Approach and Solution

Northstar adopts the following architecture:

1. Federated identity is connected to the organisation’s directory, with multi-factor authentication for all staff and separate privileged accounts.
2. Role-based access is applied to students, tutors, support staff, developers and administrators.
3. Public access is limited to a web front end and protected API gateway; databases and management interfaces use private network paths.
4. Sensitive data is encrypted in transit and at rest, with keys managed separately from application administrators.
5. Secrets are moved to a secrets-management service and are issued through controlled workload identities.
6. Infrastructure is deployed through reviewed infrastructure-as-code pipelines.
7. Central logging records authentication, administrative actions and access to student data.
8. Immutable, separately administered backups are created and restoration is tested against the RPO and RTO.
9. Continuous configuration checks detect public storage, excessive permissions and disabled logging.
10. Contracts define breach notification, data location, deletion and exit requirements.

Outcome

The redesign reduces unnecessary exposure and makes control ownership explicit. Northstar gains better audit evidence, more reliable recovery and improved scaling. It still retains residual risks, including application vulnerabilities, compromised user accounts and provider outages. These are managed through testing, monitoring, training, insurance where appropriate and periodic reassessment.

Learning Points

The case demonstrates that cloud security is an architectural and governance responsibility, not merely a procurement decision. Managed services reduce some operational work but do not eliminate the need for secure identities, data governance, monitoring, testing and accountable ownership.

9. Contemporary Developments and Limitations

Cloud-native security increasingly uses policy as code, automated posture management, workload identities, confidential computing, software supply-chain controls and extended detection across cloud and endpoint environments. Artificial intelligence can assist with log analysis, anomaly detection and prioritisation, but it may generate false positives, expose sensitive telemetry or be manipulated by attackers. AI-generated infrastructure and code require human review, testing and approval.

Containers and orchestration platforms introduce additional layers, including image provenance, cluster administration, admission controls, workload isolation and runtime monitoring. Edge computing distributes processing closer to users and devices, increasing the importance of physical, identity and connectivity controls.

Cloud security also has limitations. Abstraction can reduce visibility, provider APIs change, proprietary services may create lock-in, and a multi-cloud strategy can increase complexity rather than automatically improve resilience. Security controls may fail during migration, disaster recovery or temporary troubleshooting. Effective security therefore depends on continuous assurance, not a one-time architecture diagram.

10. Best-Practice Checklist

Before approving a cloud workload, ask:

• Is the data classified and is the processing legally justified?
• Is the deployment and service model documented?
• Is the provider/customer responsibility boundary explicit?
• Are identities, privileges and service accounts controlled?
• Are public exposure and network paths deliberately designed?
• Are secrets and encryption keys managed appropriately?
• Are code, images and infrastructure configurations reviewed?
• Are logs protected, monitored and connected to incident response?
• Are backups independent and restoration tested?
• Are RTO, RPO, service limits and exit plans documented?
• Are supplier, subprocessor, residency and breach obligations understood?
• Are cost, performance and security changes continuously monitored?

Chapter Summary

Cloud computing provides on-demand, elastic and measured access to shared technology resources. Public, private, hybrid and multi-cloud models differ in ownership, integration and operational complexity. IaaS provides infrastructure, PaaS provides a managed development platform, SaaS provides a complete application, and serverless provides managed execution. As services become more managed, the provider assumes more technical responsibility, but the customer remains responsible for secure use, data, identity, configuration and governance.

The shared-responsibility model is central to cloud security. Organisations should document the boundary for every service rather than relying on general assumptions. Effective risk assessment identifies assets, classifies data, considers threats and vulnerabilities, evaluates likelihood and impact, assigns owners and monitors residual risk.

Secure cloud architecture is identity-centred and includes least privilege, strong authentication, segmentation, encryption, managed secrets, secure development, logging, monitoring, tested recovery and supplier governance. Cloud adoption can improve agility and resilience, but only when security and accountability are designed into the service lifecycle.

Key Terms

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

Public cloud: Cloud infrastructure operated by a third-party provider for multiple customers.

Private cloud: Cloud environment dedicated to one organisation.

Hybrid cloud: Integrated use of private and public cloud environments.

Multi-cloud: Use of services from two or more cloud providers.

IaaS: Infrastructure as a Service, providing virtualised compute, storage and networking.

PaaS: Platform as a Service, providing a managed application platform.

SaaS: Software as a Service, providing a complete hosted application.

Serverless: A cloud execution model in which the provider manages server allocation and scaling.

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

Least privilege: Granting only the access necessary for an approved task.

Federated identity: Identity trust established between separate identity systems.

Managed identity: A service identity whose credentials are issued and managed by the platform.

Infrastructure as code: Machine-readable definition and deployment of infrastructure configuration.

RTO: Recovery time objective; the maximum acceptable restoration time.

RPO: Recovery point objective; the maximum acceptable data-loss period.

Residual risk: Risk remaining after controls and treatments are applied.

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

Cloud governance: Policies, roles and processes controlling cloud adoption and operation.

Review Questions

5 Short Answer Questions

1. What is the main difference between hybrid cloud and multi-cloud?
2. Which responsibilities normally remain with a SaaS customer?
3. Define least privilege in a cloud environment.
4. What do RTO and RPO measure?
5. Why is a provider compliance certification not proof that a customer configuration is secure?

5 Long Answer Questions

1. Compare public, private, hybrid and multi-cloud models, including suitable use cases and security challenges.
2. Explain how the shared-responsibility boundary changes from IaaS to PaaS, SaaS and serverless.
3. Describe a systematic cloud risk-assessment process for a system containing confidential personal data.
4. Explain how identity, network segmentation, encryption, logging and recovery controls work together in a secure cloud architecture.
5. Discuss the governance, contractual and ethical issues an organisation should consider before migrating a critical workload.

3 Analytical / Application Questions

1. A company stores a database on a public address, uses shared administrator credentials and has no tested backups. Analyse the risks and propose a prioritised remediation plan.
2. An organisation proposes multi-cloud solely because it believes this automatically guarantees availability. Evaluate the claim and identify the additional technical and governance requirements.
3. Design a responsibility matrix for a serverless application processing student records. Identify customer responsibilities, provider responsibilities, evidence and review activities.

Multiple Choice Questions with Answers

Question 1

Which deployment model combines private and public cloud environments with integration between them?

A. Public cloud

B. Private cloud

C. Hybrid cloud

D. Multi-tenant SaaS

Correct Answer: C. Hybrid cloud

Question 2

In an IaaS service, which activity is normally the customer’s responsibility?

A. Maintaining the provider’s physical power systems

B. Patching the guest operating system

C. Replacing failed provider hardware

D. Securing the provider’s data-centre entrance

Correct Answer: B. Patching the guest operating system

Question 3

Which statement best describes SaaS security responsibility?

A. The customer has no security responsibility

B. The customer manages physical servers

C. The customer remains responsible for users, access and data governance

D. The provider automatically classifies all customer data correctly

Correct Answer: C. The customer remains responsible for users, access and data governance

Question 4

What is the principal purpose of multi-factor authentication?

A. To increase storage capacity

B. To require more than one type of authentication evidence

C. To encrypt every database automatically

D. To eliminate the need for access reviews

Correct Answer: B. To require more than one type of authentication evidence

Question 5

A risk is scored with likelihood 4 and impact 5 using the chapter’s ordinal model. What is the resulting risk rating?

A. 1

B. 9

C. 20

D. 45

Correct Answer: C. 20

Question 6

Which control most directly reduces the risk of hard-coded application credentials?

A. A public IP address

B. A secrets-management service

C. A larger virtual machine

D. A longer data-retention period

Correct Answer: B. A secrets-management service

Question 7

What does an RPO of 15 minutes specify?

A. The maximum intended service restoration time is 15 minutes

B. The system must authenticate users every 15 minutes

C. The intended maximum data-loss period is approximately 15 minutes

D. The provider must retain logs for 15 minutes

Correct Answer: C. The intended maximum data-loss period is approximately 15 minutes

Question 8

Which statement about serverless computing is correct?

A. It removes the need to secure application code

B. It means no infrastructure exists

C. The customer still manages code, permissions, triggers and data

D. It requires customers to patch every physical server

Correct Answer: C. The customer still manages code, permissions, triggers and data

Question 9

Which architecture choice best limits direct exposure of a database?

A. Placing the database on a public address

B. Using private network paths and restricting access

C. Sharing one administrator account

D. Disabling all monitoring

Correct Answer: B. Using private network paths and restricting access

Question 10

Why should cloud responsibility matrices be documented?

A. To make all controls the provider’s responsibility

B. To identify accountable parties, evidence and review duties

C. To avoid classifying data

D. To guarantee that outages cannot occur

Correct Answer: B. To identify accountable parties, evidence and review duties