Cloud Security, Identity and Privacy

Introduction

Cloud computing changes where applications run, where data is stored, and how access is administered. Instead of protecting a single organisational network, a cloud security team must protect identities, application interfaces, workloads, data, configurations, networks, and relationships with cloud providers and third parties. Security is therefore not a product added after deployment; it is a set of risk-management practices embedded throughout the system lifecycle.

Cloud security also follows a shared-responsibility model. The provider generally secures the physical facilities, hardware, foundational networking, and managed-service infrastructure. The customer remains responsible for the security of its data, identities, permissions, configurations, applications, and—depending on the service model—operating systems and networks. The exact boundary differs among infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). Misunderstanding this boundary is a common cause of breaches.

Learning Objectives

After completing this chapter, a student should be able to:

1. Explain major cloud threats and the shared-responsibility model.
2. Design basic identity and access management (IAM) using least privilege.
3. Explain federation, multifactor authentication, and zero-trust principles.
4. Select suitable controls for encryption, key management, and secrets management.
5. Analyse cloud network, vulnerability, configuration, and monitoring controls.
6. Discuss privacy, governance, regulatory responsibilities, and ethical issues.
7. Apply these concepts to a realistic cloud-security scenario.

1. The Cloud Security Risk Environment

Cloud environments provide elasticity and rapid provisioning, but these strengths can also increase risk. A developer can create a database, service account, or public endpoint in minutes. If that resource is poorly configured, the exposure may remain unnoticed because traditional perimeter controls do not necessarily inspect it.

Important threat categories include:

• Credential compromise: stolen passwords, tokens, API keys, or session cookies allow attackers to act as legitimate users.
• Excessive privilege: a user, workload, or service account can perform more actions than necessary.
• Insecure interfaces: vulnerable APIs may permit data disclosure, unauthorised actions, or denial of service.
• Misconfiguration: storage, databases, security groups, identity policies, or logging may be unintentionally exposed.
• Vulnerable software: weaknesses in operating systems, containers, libraries, images, and applications may be exploited.
• Insider misuse: authorised personnel may intentionally or accidentally misuse access.
• Supply-chain compromise: a dependency, build tool, image, managed service, or vendor may introduce malicious code or weakness.
• Data loss and availability failure: deletion, ransomware, provider outage, or inadequate backup may affect business operations.
• Inadequate monitoring: without reliable logs and alerts, an organisation may not detect or investigate an attack.

A useful security analysis considers confidentiality, integrity, and availability (the CIA triad). Privacy adds a further concern: information may be processed lawfully and securely yet still be used in ways that violate individual expectations or rights.

Shared Responsibility

Responsibility is divided according to the service model. In IaaS, the customer commonly manages guest operating systems, applications, identities, virtual networks, and data. In PaaS, the provider manages more of the runtime and operating platform, while the customer still secures code, identities, data, and configuration. In SaaS, the provider operates most technical infrastructure, but the customer remains responsible for account governance, data classification, access settings, and appropriate use.

The model is not a transfer of accountability. A provider may supply secure capabilities, but the customer must configure and use them correctly. Contracts, service-level agreements, audit reports, incident-notification provisions, data-location terms, and exit arrangements should therefore be reviewed before deployment.

2. Identity and Access Management

IAM answers four related questions:

1. Who or what is requesting access? This is identification.
2. Can the claimed identity be trusted? This is authentication.
3. What may the identity do? This is authorisation.
4. What did the identity do? This is accountability through logging and audit.

Cloud identities include human users, administrators, applications, virtual machines, containers, serverless functions, automation pipelines, and external partners. Treating workloads as identities is essential because modern applications often call cloud APIs without direct human involvement.

Authentication and Multifactor Authentication

Authentication factors are commonly classified as:

• something the user knows, such as a password;
• something the user has, such as a hardware security key or authenticator device; and
• something the user is, such as a biometric characteristic.

Multifactor authentication (MFA) combines independent factors. A password plus a second password is not true multifactor authentication because both are knowledge factors. Phishing-resistant methods, including hardware-backed security keys and passkeys based on public-key cryptography, provide stronger protection than passwords and many one-time codes.

Administrative and high-risk operations should require strong MFA, often with step-up authentication. Passwords should be long, unique, protected against automated guessing, and never stored in plain text. Systems should store passwords using an appropriate slow, salted password-hashing scheme rather than reversible encryption.

Authorisation Models

Common authorisation approaches include:

• Role-based access control (RBAC): permissions are assigned to roles, and users receive roles according to their job functions.
• Attribute-based access control (ABAC): decisions use attributes such as department, resource classification, device status, time, location, or workload identity.
• Policy-based access control: explicit policies evaluate a request against subjects, actions, resources, and conditions.
• Discretionary access control: resource owners may grant access, which can be flexible but difficult to govern.

RBAC is understandable and useful for stable responsibilities, but role proliferation can occur when every exception becomes a new role. ABAC and policy conditions provide greater precision but demand good-quality attributes, policy testing, and administrative maturity.

Least Privilege and Separation of Duties

Least privilege means granting only the permissions needed for an approved task, for only as long as necessary. It applies to humans and workloads. A read-only analytics service should not be able to delete production databases. A deployment pipeline should deploy only to its intended environments and should not possess unrestricted administrative access.

Practical controls include separate administrative and ordinary accounts, just-in-time elevation, short-lived credentials, approval for sensitive actions, permission reviews, deny-by-default policies, and automated detection of unused permissions. Separation of duties prevents one person or identity from independently completing a high-risk process, such as creating a supplier and approving payment.

3. Federation and Zero Trust

Federation allows one organisation or identity provider to authenticate a user for another service. Standards such as Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and OAuth 2.0 are widely used, although they serve different purposes. OIDC provides identity information on top of OAuth 2.0; OAuth primarily delegates authorisation rather than proving identity. SAML commonly exchanges signed assertions between an identity provider and a service provider.

Federation reduces password duplication and supports centralised lifecycle management. However, compromise of the identity provider can affect many services. Federation therefore requires strong protection of the provider, careful validation of issuer and audience values, secure token lifetimes, key rotation, and rapid account deprovisioning.

Zero trust is a security model based on the principle that no user, device, workload, or network location should receive implicit trust. Access is continuously evaluated using identity, device posture, resource sensitivity, context, and observed behaviour. Zero trust does not mean that every request must be manually approved; it means that trust is explicit, policy-based, and repeatedly assessed.

A practical zero-trust architecture may include central identity, phishing-resistant MFA, device management, workload identity, micro-segmentation, encrypted communication, policy enforcement points, and continuous logging. Network location alone is not a sufficient authorisation signal.

4. Encryption, Keys, and Secrets

Encryption transforms readable plaintext into ciphertext using an algorithm and a key. Confidentiality depends not merely on selecting an algorithm but on protecting keys, authenticating messages, managing access, and avoiding insecure implementation.

• Encryption in transit protects data moving between clients, services, and administrative interfaces. Transport Layer Security (TLS) should be correctly configured, with certificate validation and obsolete protocols disabled.
• Encryption at rest protects stored data, backups, disks, and object-storage contents. It reduces exposure if storage media or snapshots are accessed improperly, but it does not replace IAM.
• Application-level or client-side encryption gives the customer greater control because plaintext may never be visible to the provider, although searching, processing, recovery, and key availability become more difficult.

Authenticated encryption provides confidentiality and integrity. A simplified security relationship is:

Here, P is plaintext, K is the secret key, N is a unique nonce, A is associated data that is authenticated but not encrypted, and C is the resulting ciphertext with authentication information. The notation represents an authenticated-encryption operation, not a universal algorithm. The nonce must satisfy the selected algorithm’s uniqueness requirements, and keys must remain secret.

Key Management

A key-management service or hardware security module can generate, store, use, rotate, disable, and audit cryptographic keys. Important lifecycle stages are generation, distribution, activation, rotation, backup, revocation, archival, and destruction. Key access should be separated from ordinary data access where feasible. Organisations should define who can administer keys, who can use them, how emergency recovery works, and how loss of a key affects business continuity.

Envelope encryption is common in cloud services. A data-encryption key (DEK) encrypts the data, while a key-encryption key (KEK) encrypts the DEK. The encrypted DEK is stored with the ciphertext, and access to the KEK is controlled separately. This permits efficient data encryption while centralising protection of higher-level keys.

Secrets Management

Passwords, database credentials, API tokens, private keys, and certificates are secrets. They should not be embedded in source code, container images, chat messages, or public configuration files. A secrets manager can provide controlled retrieval, auditing, rotation, versioning, and narrowly scoped access. Applications should retrieve secrets at runtime using workload identity, and leaked secrets should be revoked rather than merely deleted from a repository.

5. Network and Workload Security

Cloud network security is implemented through virtual networks, subnets, route controls, security groups or network security rules, firewalls, web application firewalls, private service endpoints, and denial-of-service protections. Public exposure should be deliberate and minimal. Administrative interfaces should not be directly reachable from the public internet unless a strong, justified design requires it.

Segmentation limits the impact of compromise. Public-facing components can be separated from application services, which can be separated from databases. Egress controls are also important: a compromised workload may otherwise communicate freely with command-and-control infrastructure or exfiltrate data.

Containers and serverless functions introduce additional concerns. Images should be sourced from trusted registries, scanned before deployment, signed where practical, and built from minimal base images. Runtime permissions should be restricted. Serverless functions should have narrowly scoped execution roles, controlled dependencies, and monitored invocation paths. Kubernetes and similar orchestrators require protection of the control plane, admission policies, secrets, namespaces, and service accounts.

6. Vulnerability Management and Secure Configuration

Vulnerability management is a continuous process rather than a one-time scan. It includes asset discovery, software and dependency identification, vulnerability assessment, prioritisation, remediation, verification, and exception management. Priority should reflect exploitability, exposure, business impact, asset criticality, and available compensating controls—not only a numerical severity score.

A secure configuration baseline defines approved settings for operating systems, cloud services, storage, identity, logging, and networks. Configuration-as-code enables review, repeatability, and automated testing. Policy-as-code can prevent prohibited resources from being deployed, such as publicly readable storage or databases lacking encryption.

A secure development lifecycle should include threat modelling, code review, dependency scanning, secret detection, static and dynamic testing, infrastructure scanning, signed builds, and controlled promotion between environments. Production changes should be traceable and reversible. Vulnerability exceptions must have an owner, justification, expiry date, and compensating controls.

7. Monitoring, Detection, and Response

Security monitoring requires logs that are complete, time-synchronised, protected from tampering, and retained according to risk and legal requirements. Useful sources include identity events, administrative actions, network flows, application logs, data-access events, configuration changes, vulnerability findings, and provider audit trails.

A security information and event management (SIEM) platform can aggregate and correlate events. Detection engineering should focus on meaningful behaviours, such as impossible-travel sign-ins, creation of access keys, disabling of logging, unusual data downloads, privilege escalation, anomalous egress, and access to sensitive resources from unfamiliar contexts.

Monitoring without response is incomplete. An incident-response plan should define preparation, detection and analysis, containment, eradication, recovery, notification, and lessons learned. Backups should be protected from alteration, tested through restoration exercises, and separated from ordinary administrative privileges. Forensic readiness requires reliable timestamps, preserved evidence, documented access, and appropriate legal coordination.

8. Privacy and Data Governance

Security protects systems and information from threats; privacy governs how information about people is collected, used, shared, retained, and deleted. Privacy principles commonly include purpose limitation, data minimisation, transparency, accuracy, retention limitation, integrity, confidentiality, and accountability. Applicable obligations depend on jurisdiction, sector, data type, and organisational role.

A cloud privacy programme should address:

• data classification and discovery;
• lawful purpose and consent where required;
• records of processing and data-flow mapping;
• data residency and international transfer requirements;
• processor and subprocessor due diligence;
• retention and defensible deletion;
• individual rights and access requests;
• breach assessment and notification;
• privacy impact assessments for high-risk processing; and
• de-identification, pseudonymisation, or tokenisation where appropriate.

Pseudonymisation reduces direct identifiability but does not necessarily make data anonymous, because additional information may permit re-identification. Encryption protects confidentiality but does not by itself make processing lawful. Privacy-preserving design must therefore combine technical controls with governance and ethical judgement.

Artificial intelligence creates additional privacy and security concerns. Training and inference may expose personal or confidential information, models may memorise sensitive data, and prompts may cause unintended disclosure. Organisations should classify AI inputs, restrict retention, test access boundaries, validate vendors, and maintain human accountability for consequential decisions.

9. Applied Case: Northstar Health Services

Background

Northstar Health Services, an illustrative regional provider, moves its appointment and diagnostic platform to the cloud. The platform includes a public web application, clinician portal, patient records, analytics, and an automated deployment pipeline.

Problem

An assessment finds that a storage bucket is publicly readable, developers share a long-lived database credential, administrators use password-only authentication, and audit logs are retained in the same account that generates them. The organisation also cannot determine where backups are processed by subcontractors.

Analysis

The public bucket creates a confidentiality risk. Shared credentials weaken attribution and increase the impact of compromise. Password-only administration increases the probability of account takeover. Mutable logs may be deleted by an attacker. Unclear subcontractor processing creates privacy and contractual risk. The issues are interconnected: weak identity controls can enable configuration changes, while poor monitoring delays detection.

Approach and Solution

Northstar first classifies patient records as highly sensitive and establishes a responsibility matrix with its cloud provider. It removes public access, applies deny-by-default storage policies, and scans all repositories for exposed secrets. A managed secrets service replaces the shared credential, and applications receive short-lived workload credentials.

The organisation introduces a central identity provider, phishing-resistant MFA for privileged users, separate administrative accounts, just-in-time elevation, and quarterly access reviews. Network segmentation places the public application, internal services, and databases in separate zones. Encryption is enabled in transit and at rest, with customer-controlled key policies for the most sensitive datasets.

Infrastructure is deployed through reviewed code. Policy checks block public storage, unrestricted administrative ports, and resources without logging. Audit events are copied to a separate security account with restricted deletion rights and monitored alerts. Backups are encrypted, isolated, and restored periodically. Privacy staff document data flows, retention periods, subprocessors, and cross-border transfers.

Outcome

Northstar reduces standing privilege, improves attribution, limits public exposure, and gains evidence for incident investigation and regulatory review. It does not eliminate risk: phishing, provider outage, software vulnerabilities, and insider misuse remain possible. The organisation therefore maintains continuous testing, staff training, incident exercises, and governance reviews.

Learning Points

The case demonstrates that cloud security is systemic. Encryption cannot compensate for excessive permissions; MFA cannot compensate for insecure storage policies; and monitoring cannot compensate for the absence of an incident plan. Effective security combines identity, configuration, network, data, privacy, and operational controls.

10. Governance, Ethics, and Professional Practice

Security professionals must balance protection, usability, cost, resilience, and individual rights. Excessive surveillance can create privacy harms even when intended to improve security. Automated risk scoring may discriminate if data or models are biased. Administrators should collect only necessary monitoring data, restrict its use, communicate policies clearly, and retain it for justified periods.

Organisations should align controls with recognised frameworks and obligations, such as an information-security management system, cloud-security control catalogues, privacy regulations, and sector-specific standards. Frameworks are aids to reasoning, not substitutes for risk assessment. A control that is appropriate for a payment system may be inappropriate or insufficient for a research environment.

Best-Practice Checklist

• Maintain an accurate inventory of cloud accounts, resources, data, and dependencies.
• Use central identity, strong MFA, federation, and lifecycle automation.
• Apply least privilege, short-lived credentials, separation of duties, and regular reviews.
• Encrypt sensitive data in transit and at rest; protect and audit keys separately.
• Store secrets in managed systems, rotate them, and detect accidental exposure.
• Minimise public exposure and implement segmentation and egress controls.
• Use secure baselines, policy-as-code, vulnerability management, and signed deployments.
• Centralise tamper-resistant logs and test alerting and incident response.
• Map data flows, minimise collection, control retention, and assess subprocessors.
• Test backup restoration, disaster recovery, and access-revocation procedures.

Chapter Summary

Cloud security is a shared responsibility requiring coordinated protection of identities, workloads, networks, configurations, applications, and data. IAM establishes identification, authentication, authorisation, and accountability. Least privilege, separation of duties, MFA, federation, workload identities, and zero-trust principles reduce unauthorised access and limit compromise.

Encryption protects confidentiality and integrity when algorithms, keys, nonces, certificates, and access policies are properly managed. Key-management services, envelope encryption, and secrets managers support secure lifecycle control. Network segmentation, secure images, vulnerability management, configuration baselines, infrastructure-as-code, and policy-as-code reduce technical exposure.

Effective security also depends on protected logs, meaningful detection, tested response, resilient backups, and clear governance. Privacy is broader than encryption: it concerns lawful, transparent, proportionate, and ethical processing of personal information. Cloud security is therefore a continuous socio-technical practice rather than a single configuration task.

Key Terms

IAM: The governance and technical control of digital identities and their permissions.

Authentication: Verification that an identity is genuine.

Authorisation: Determination of what an authenticated identity may do.

Least privilege: Granting only the minimum permissions required for an approved task.

MFA: Authentication using two or more independent factor types.

Federation: Trust that allows one identity provider to authenticate users for another service.

Zero trust: A model that grants no implicit trust based solely on network location.

RBAC: Access control based on assigned organisational roles.

ABAC: Access control based on attributes and policy conditions.

Workload identity: A digital identity assigned to an application, service, or automated process.

Encryption at rest: Protection of stored data using cryptography.

Encryption in transit: Protection of data while moving between systems.

DEK: Data-encryption key used to encrypt data.

KEK: Key-encryption key used to protect a data-encryption key.

Secrets manager: A controlled system for storing and delivering credentials and other secrets.

Configuration drift: Unintended divergence from an approved system baseline.

Vulnerability management: The process of finding, prioritising, fixing, and verifying weaknesses.

SIEM: A platform that collects and correlates security events.

Pseudonymisation: Replacing identifying values while retaining a possibility of re-identification.

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

Review Questions

Short Answer Questions

1. What are the four principal functions of IAM?
2. Why is least privilege important for workload identities?
3. Distinguish encryption at rest from encryption in transit.
4. What is the purpose of a secrets manager?
5. Why does privacy require more than encryption?

Long Answer Questions

1. Explain the shared-responsibility model across IaaS, PaaS, and SaaS, using examples of customer and provider duties.
2. Compare RBAC and ABAC, including their strengths, limitations, and suitable use cases.
3. Explain how federation, MFA, and zero trust can be combined in a cloud architecture.
4. Describe a complete vulnerability and secure-configuration management lifecycle.
5. Discuss how cloud monitoring, incident response, backup protection, and privacy governance support one another.

Analytical / Application Questions

1. A company discovers that a production application uses an administrator role to read a customer database. Analyse the risks and propose a least-privilege redesign.
2. Design a security architecture for a cloud-based healthcare application containing a public web tier, private application services, and sensitive records. Justify your identity, network, encryption, monitoring, and privacy controls.
3. An attacker obtains a developer’s API token and downloads unusual quantities of data. Develop an incident-response sequence and identify preventive controls that should be implemented afterward.

Multiple Choice Questions with Answers

Question 1

Which control most directly enforces least privilege for a cloud workload?

A. Assigning the workload an unrestricted administrator role

B. Granting only the specific read permission required for its task

C. Allowing access from any network without authentication

D. Disabling audit logging to improve performance

Correct Answer: B. Granting only the specific read permission required for its task

Question 2

What does federation primarily allow?

A. A storage device to encrypt data without a key

B. A provider to operate without customer responsibility

C. One identity provider to authenticate users for another service

D. A firewall to replace identity management

Correct Answer: C. One identity provider to authenticate users for another service

Question 3

Which statement best describes zero trust?

A. Internal network traffic is always trusted

B. Trust is granted permanently after the first login

C. Only physical devices require authentication

D. Access is explicitly and continuously evaluated rather than assumed

Correct Answer: D. Access is explicitly and continuously evaluated rather than assumed

Question 4

In envelope encryption, what normally encrypts the data-encryption key?

A. The key-encryption key

B. The plaintext database

C. The public web server

D. The audit log

Correct Answer: A. The key-encryption key

Question 5

Which practice is most appropriate for cloud secrets?

A. Embedding database passwords in source code

B. Posting API tokens in a team chat

C. Storing and retrieving them through a managed secrets service

D. Using one permanent credential for every application

Correct Answer: C. Storing and retrieving them through a managed secrets service

Question 6

Which control most directly limits lateral movement between cloud components?

A. Network segmentation

B. A longer project name

C. Disabling password rotation

D. Publicly exposing databases

Correct Answer: A. Network segmentation

Question 7

What is the primary purpose of policy-as-code?

A. To replace all human security decisions

B. To automatically test or block resources that violate defined rules

C. To make encryption unnecessary

D. To guarantee that no vulnerability can ever exist

Correct Answer: B. To automatically test or block resources that violate defined rules

Question 8

Which characteristic is most important for security audit logs?

A. They can be freely deleted by the account being monitored

B. They are protected from unauthorised alteration and deletion

C. They record only successful logins

D. They are retained only on an administrator’s laptop

Correct Answer: B. They are protected from unauthorised alteration and deletion

Question 9

Which statement about pseudonymisation is correct?

A. It always makes data permanently anonymous

B. It replaces identifying values but may still permit re-identification

C. It eliminates the need for access control

D. It is identical to deleting all personal data

Correct Answer: B. It replaces identifying values but may still permit re-identification

Question 10

A public storage resource contains sensitive records. Which response is the highest immediate priority?

A. Increase the public read permission

B. Disable logging to avoid alert noise

C. Remove unintended public access and preserve evidence for investigation

D. Wait for the next annual security review

Correct Answer: C. Remove unintended public access and preserve evidence for investigation