Identity, Security, Privacy, and Compliance

Introduction

Cloud computing changes where applications, data, and security controls are operated. Instead of protecting only a physically controlled data centre, an organisation must govern identities, networks, software, data, suppliers, and administrative actions across shared infrastructure. Cloud providers secure the underlying facilities and services, but customers remain responsible for correctly configuring accounts, permissions, data protection, workloads, and compliance controls. This division is expressed through the shared responsibility model.

Security in cloud architecture is therefore not a single product or perimeter. It is a system of preventive, detective, corrective, and governance controls. Identity and access management (IAM) determines who or what may perform an action. Encryption protects information from unauthorised disclosure. Logging supports detection and accountability. Vulnerability management reduces exploitable weaknesses. Privacy controls govern personal information, while compliance demonstrates that legal, contractual, and industry obligations are being met.

This chapter develops the practical foundations required to design and operate secure cloud environments.

Learning Objectives

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

1. Explain the shared responsibility model and the security objectives of confidentiality, integrity, and availability.
2. Design basic IAM policies using authentication, authorisation, federation, and least privilege.
3. Distinguish encryption in transit, at rest, and in use, and explain key-management practices.
4. Protect secrets and credentials in cloud applications.
5. Use logging, monitoring, vulnerability management, and incident-response controls.
6. Apply privacy principles to cloud data and recognise common compliance responsibilities.
7. Evaluate a cloud-security design and recommend practical improvements.

1. Security Foundations for Cloud Architecture

1.1 The CIA triad

The three traditional security objectives are:

• Confidentiality: information is disclosed only to authorised parties.
• Integrity: information remains accurate, complete, and protected from unauthorised alteration.
• Availability: authorised users can access systems and information when required.

These objectives can conflict. Strong confidentiality controls may add authentication steps; extensive integrity checks may consume computing resources; high availability may require replicated copies that increase the number of locations requiring protection. Architecture is therefore a risk-based process rather than an attempt to maximise one objective independently.

Other important properties include authenticity, proving that an identity or message is genuine; accountability, associating actions with responsible subjects; and non-repudiation, providing evidence that an action or transaction occurred and is difficult for its originator to deny.

1.2 Threats, vulnerabilities, and risk

A threat is a potential cause of harm, such as credential theft, malicious software, or accidental deletion. A vulnerability is a weakness that a threat may exploit. Risk is the possibility that a threat will exploit a vulnerability and produce an impact. Risk assessment considers assets, threat likelihood, and consequences, but numerical precision should not be implied when estimates are uncertain.

Controls may be:

• Preventive, such as multifactor authentication and network restrictions;
• Detective, such as audit logs and intrusion alerts;
• Corrective, such as restoring from backups or rotating compromised keys;
• Deterrent, such as contractual sanctions and visible monitoring;
• Compensating, used when a preferred control cannot reasonably be implemented.

Defence in depth combines controls so that failure of one layer does not automatically produce compromise.

1.3 The shared responsibility model

The provider normally protects the cloud infrastructure: buildings, physical hosts, core networking, and the managed service platform. The customer normally protects identities, configurations, operating systems in customer-managed services, applications, data, and access policies. Responsibility varies by service model:

The exact boundary must be confirmed in the provider’s documentation and contract. A managed service is not automatically a secure service; poor permissions or exposed data can still be the customer’s responsibility.

2. Identity and Access Management

2.1 Identity concepts

An identity represents a person, workload, device, or service. An account is a record through which an identity is recognised. A credential is evidence used to authenticate an identity. Authentication answers “Who or what are you?” Authorisation answers “What are you allowed to do?” Accounting or auditing records what was done.

A sound IAM lifecycle includes joiner, mover, and leaver processes. New users receive only required access; changes in role trigger review and adjustment; departing users are promptly disabled. Privileged accounts should be separate from ordinary user accounts, and shared accounts should be avoided because they weaken accountability.

2.2 Authentication and federation

Authentication factors generally belong to three categories:

1. Something you know, such as a password or PIN.
2. Something you have, such as a hardware security key or authenticator device.
3. Something you are, such as a fingerprint or facial characteristic.

Multifactor authentication (MFA) combines factors from different categories. A second password is not normally a different factor. Phishing-resistant methods, including hardware-backed security keys and standards such as FIDO2/WebAuthn, provide stronger protection than one-time codes transmitted through vulnerable channels.

Federation allows a trusted identity provider to authenticate a user for another service. Standards such as SAML and OpenID Connect support this pattern. Federation reduces password duplication and centralises lifecycle management, but trust relationships, token audiences, signing keys, redirect locations, and logout behaviour must be configured carefully.

2.3 Authorisation models

Common authorisation models include:

• Role-based access control (RBAC): permissions are assigned to job or system roles.
• Attribute-based access control (ABAC): decisions use attributes such as department, resource classification, device state, and location.
• Policy-based access control: rules evaluate subjects, actions, resources, and conditions.
• Mandatory access control: centrally enforced classifications constrain access.

RBAC is understandable and practical, but roles can proliferate. ABAC is expressive, but depends on accurate attributes and careful policy testing. Many cloud systems combine roles with resource policies and contextual conditions.

2.4 Least privilege and zero trust

Least privilege grants only the permissions, duration, and scope necessary for an approved task. It applies to users, applications, automation pipelines, and administrators. Permissions should be granted to groups or roles where possible, rather than individually, and should be reviewed for unused or excessive access.

A useful practical test is: can the identity read, modify, delete, or administer resources beyond its task? If yes, reduce the scope, use conditions, or introduce temporary elevation. Just-in-time privilege provides elevated access for a limited period after approval. Separation of duties ensures that one person cannot independently perform incompatible actions, such as creating and approving a financial payment.

Zero-trust architecture does not mean that every request is rejected. It means that trust is not granted merely because a request originates inside a network. Each request is evaluated using identity, device, resource, policy, and contextual signals, with continuous monitoring.

3. Encryption and Key Management

3.1 Encryption states

Encryption transforms readable plaintext into ciphertext using an algorithm and key. It should be applied in three states:

• In transit: protects network communication, typically with TLS. Certificates must be validated, obsolete protocols disabled, and mutual TLS considered for service-to-service authentication.
• At rest: protects stored databases, disks, object stores, backups, and snapshots. Encryption does not replace access control because an authorised service can usually decrypt data.
• In use: protects data while being processed. Confidential-computing technologies can reduce exposure in memory, but they add complexity and do not remove the need for application and identity controls.

Encryption provides confidentiality, but integrity and authenticity require authenticated encryption, message authentication, digital signatures, or equivalent mechanisms. A hash function is not encryption: it is a one-way transformation used for integrity checks and, with suitable password-hashing algorithms, credential protection.

3.2 Key-management lifecycle

Keys require governance throughout their lifecycle: generation, activation, distribution, storage, rotation, revocation, backup, archival, and destruction. Keys should be generated using approved cryptographic random sources and protected in a key-management service or hardware security module where appropriate.

A key-encryption key may protect data-encryption keys. This envelope-encryption arrangement limits direct exposure of master keys and supports controlled rotation. Rotation does not necessarily re-encrypt every historical object; the organisation must understand the provider’s rotation semantics and retention requirements.

Access to keys must be logged and restricted. Key administrators should not automatically have permission to read business data, supporting separation of duties. Lost keys may make encrypted data permanently inaccessible, so recovery and escrow arrangements must be tested and governed.

3.3 Passwords and secrets

Passwords should not be stored in plaintext or reversible encryption. They should be processed using a password-specific, salted, adaptive hashing function. Application secrets—API tokens, database passwords, private keys, and signing credentials—should be stored in a dedicated secrets manager, not in source code, container images, tickets, or ordinary configuration files.

Secrets management should provide access policies, audit trails, automated rotation where feasible, versioning, and emergency revocation. Applications should retrieve secrets at runtime through workload identity rather than embedding long-lived credentials. Secret scanning belongs in source-control and CI/CD pipelines, although scanning is not a substitute for immediate revocation when exposure occurs.

4. Logging, Monitoring, and Vulnerability Management

4.1 Security logging

Cloud audit logs should capture authentication events, administrative actions, policy changes, key use, network security changes, data access where available, and control-plane API calls. Logs should be centralised in a separate security account or project, protected from alteration, time-synchronised, and retained according to operational, legal, and privacy requirements.

A useful log record identifies the actor, action, resource, timestamp, result, source, and correlation identifier. Excessive collection can create privacy and cost concerns; insufficient collection prevents investigation. Sensitive values such as passwords, tokens, and unnecessary personal data should not be logged.

Monitoring converts events into signals. Examples include impossible-travel logins, repeated failed authentication, unusual data downloads, newly exposed storage, disabled logging, and privilege escalation. Alert thresholds should be tested to limit both missed incidents and alert fatigue.

4.2 Vulnerability management

Vulnerability management is a lifecycle, not a one-time scan:

1. Maintain an accurate inventory of assets and software.
2. Discover vulnerabilities through scanning, vendor notices, code analysis, and penetration testing.
3. Assess exploitability, exposure, business impact, and compensating controls.
4. Prioritise remediation according to risk rather than severity score alone.
5. Patch, upgrade, isolate, or otherwise mitigate.
6. Verify remediation and document exceptions.

Cloud images should be hardened, dependencies updated, unused services removed, and configuration checked continuously. Infrastructure as code enables repeatable review and reduces configuration drift. Penetration testing must follow provider rules and organisational authorisation.

4.3 Incident response and resilience

An incident plan should define preparation, identification, containment, eradication, recovery, and lessons learned. Evidence must be preserved, responsibilities assigned, and communications coordinated with legal, privacy, executive, provider, and regulatory stakeholders.

Backups should be encrypted, access-controlled, versioned where appropriate, and tested through restoration exercises. Immutability and geographic separation can reduce ransomware impact. Availability architecture should address dependency failure, but replication alone is not a backup if destructive changes replicate immediately.

5. Privacy and Compliance

5.1 Privacy principles

Privacy concerns how personal information is collected, used, disclosed, retained, secured, and deleted. Common principles include lawfulness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. Organisations should identify the purpose for processing before collecting data and avoid retaining information merely because storage is inexpensive.

A privacy impact assessment is appropriate when processing is likely to create significant risks, such as large-scale monitoring, sensitive data processing, or systematic profiling. Privacy by design incorporates safeguards in architecture from the beginning rather than adding them after deployment.

Important cloud practices include data classification, geographic and cross-border transfer analysis, pseudonymisation, access logging, retention schedules, deletion workflows, and procedures for data-subject requests. Pseudonymised data may still be personal data if re-identification remains reasonably possible.

5.2 Compliance as evidence-based governance

Compliance is not identical to security. Security controls reduce risk; compliance demonstrates that required controls and processes exist and operate. Requirements may arise from privacy law, sector regulation, contracts, internal policy, and standards such as ISO/IEC 27001 or the NIST Cybersecurity Framework. Examples of industry obligations include payment-card protection and health-information safeguards, but applicability depends on jurisdiction, activity, and data.

A compliance programme should map obligations to control objectives, owners, evidence, review frequency, and exceptions. Provider audit reports and certifications can support assurance, but they do not prove that the customer’s configuration is compliant. Contract review should address breach notification, subprocessors, data location, audit rights, deletion, availability, and exit assistance.

6. Applied Case: Northstar Health Services

The following is an illustrative case, not a description of a real organisation.

Background and problem

Northstar Health Services plans to move a patient appointment platform to the cloud. The platform stores contact details, appointment history, clinician schedules, and billing references. Developers currently use shared administrator credentials, database passwords appear in deployment scripts, audit logs are retained only on application servers, and backups have not been restoration-tested.

Analysis

The major risks are excessive privilege, weak accountability, secret exposure, incomplete detection, uncertain recovery, and possible privacy violations. The platform also has different user populations: patients, clinicians, billing staff, developers, and cloud administrators. A single broad role would violate least privilege and separation of duties.

Approach and solution

Northstar establishes a central identity provider with federation and MFA. Patients, clinicians, and staff receive distinct roles; administrators use separate privileged accounts. Applications use workload identities and narrowly scoped service roles. Temporary elevation is required for exceptional administrative tasks.

Patient and billing data are classified as sensitive. TLS protects connections, storage encryption uses provider-managed keys initially, and a dedicated key-management service is introduced for higher-risk databases. Database credentials move to a secrets manager with rotation and access logging. Source repositories are scanned for leaked credentials, and any discovered secret is revoked immediately.

Cloud audit logs are sent to a separate, access-restricted account with retention aligned to policy and law. Alerts cover disabled logging, unusual exports, privilege changes, and repeated failed authentication. Infrastructure is deployed through reviewed code, images are hardened, dependencies are patched, and vulnerability exceptions require documented approval.

A privacy assessment identifies purposes, retention periods, data flows, subprocessors, and cross-border issues. Backups are encrypted and immutable where feasible; quarterly restoration exercises verify recovery. Contracts define breach notification, deletion, data location, and provider responsibilities.

Outcome and learning points

The redesigned environment improves accountability, limits blast radius, increases detection capability, and produces evidence for audits. It does not eliminate risk: phishing, software defects, insider misuse, provider outages, and incorrect policy changes remain possible. The principal lesson is that security is an operating capability involving people, processes, technology, and continuous verification.

7. Professional Practice and Contemporary Developments

Security professionals increasingly manage identities for machines, containers, serverless functions, and AI services rather than only human users. Workload identity, short-lived credentials, software supply-chain signing, and policy-as-code reduce dependence on static secrets. Cloud security posture management tools can identify misconfigurations, but findings require human prioritisation and validation.

AI can assist with alert triage, anomaly detection, code review, and policy analysis. However, generated recommendations may be incorrect, biased, or unsafe. Sensitive logs and incident data must not be sent to an AI service without authorisation and privacy review. Human approval remains essential for high-impact access and remediation decisions.

Good practice is ultimately disciplined practice: define ownership, classify data, minimise privileges, protect keys and secrets, collect useful evidence, test recovery, review suppliers, and continuously reassess changing threats and obligations.

Challenges and Limitations

No control is perfect. MFA can be bypassed through social engineering or compromised endpoints. Encryption cannot protect data after authorised decryption or prevent misuse by an approved user. Centralised logging can become a high-value target and may generate substantial cost. Automated compliance checks can produce false positives and may not understand business context. Privacy requirements can conflict with long retention periods needed for investigations. Finally, cloud abstraction can obscure dependencies and make exit or migration difficult. These limitations reinforce the need for layered controls, clear governance, testing, and risk-based judgement.

Chapter Summary

Cloud security is based on shared responsibility, defence in depth, and continuous risk management. IAM establishes authenticated identities and carefully bounded permissions through federation, MFA, RBAC, ABAC, least privilege, separation of duties, and temporary elevation. Encryption protects data in transit, at rest, and, increasingly, in use; effective security also requires lifecycle-managed keys and protected secrets.

Audit logging, monitoring, vulnerability management, incident response, and tested backups provide detection and recovery capabilities. Privacy requires purposeful collection, minimisation, retention control, transparency, and secure processing of personal information. Compliance is an evidence-based governance activity that must be mapped to applicable laws, standards, contracts, and provider responsibilities. Secure cloud architecture is therefore both a technical and organisational discipline.

Key Terms

Access control: Rules governing which subjects may perform which actions on resources.

Authentication: Verification of an identity or entity.

Authorisation: Determination of permitted actions after authentication.

Cloud shared responsibility model: Division of security duties between provider and customer.

Confidentiality: Protection against unauthorised disclosure.

Defence in depth: Use of multiple independent or complementary security layers.

Encryption: Transformation of plaintext into protected ciphertext using a key.

Federation: Trust relationship allowing one identity provider to authenticate users for another service.

Identity and access management: Processes and technologies for identities, authentication, authorisation, and accountability.

Integrity: Protection of information against unauthorised or inaccurate alteration.

Key management: Governance of cryptographic keys throughout their lifecycle.

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

Multifactor authentication: Authentication using factors from at least two categories.

Personal information: Information relating to an identified or identifiable person.

Privacy by design: Incorporating privacy safeguards into architecture and processes from inception.

Pseudonymisation: Replacing direct identifiers while retaining a controlled possibility of linkage.

Risk: Possibility of harm arising from threats, vulnerabilities, and impacts.

Secrets manager: Controlled service for storing, accessing, auditing, and rotating sensitive credentials.

Vulnerability: A weakness that may be exploited by a threat.

Review Questions

Short Answer Questions

1. What are confidentiality, integrity, and availability?
2. Distinguish authentication from authorisation.
3. Why is least privilege important in cloud environments?
4. Name three states in which cloud data may require protection.
5. Why should audit logs be stored separately from the systems producing them?

Long Answer Questions

1. Explain the shared responsibility model across IaaS, PaaS, and SaaS, giving examples of customer responsibilities.
2. Compare RBAC and ABAC, including one strength and one limitation of each.
3. Describe a cryptographic key-management lifecycle and explain why rotation alone is not sufficient.
4. Explain how privacy principles influence cloud data collection, retention, access, and deletion.
5. Describe a complete vulnerability-management and incident-response process for a cloud application.

Analytical / Application Questions

1. A developer has permanent administrator access and a database password stored in a public code repository. Identify the risks and propose a prioritised remediation plan.
2. Design an IAM and logging approach for an online service containing customer billing and contact information. Justify the roles, authentication controls, logging events, and retention decisions.
3. A company replicates encrypted backups across two countries but has never tested restoration. Analyse the security, privacy, availability, and compliance issues and recommend next steps.

Multiple Choice Questions with Answers

Question 1

Which statement best describes authorisation?

A. Verifying a user’s identity

B. Determining what an authenticated identity may do

C. Encrypting a stored database

D. Recording an event in an audit log

Correct Answer: B. Determining what an authenticated identity may do

Question 2

Which practice most directly implements least privilege?

A. Giving every developer permanent administrator access

B. Sharing one administrator account among a team

C. Granting a service only read access to the objects it must retrieve

D. Disabling audit logging to reduce storage cost

Correct Answer: C. Granting a service only read access to the objects it must retrieve

Question 3

Which is an example of multifactor authentication?

A. A password and a second password

B. A username and an email address

C. A hardware security key and a password

D. Two security questions

Correct Answer: C. A hardware security key and a password

Question 4

What is the primary purpose of encryption in transit?

A. To protect communication while it crosses networks

B. To remove the need for access control

C. To ensure all backups are recoverable

D. To classify personal information

Correct Answer: A. To protect communication while it crosses networks

Question 5

Which item should generally be stored in a dedicated secrets manager?

A. A public product description

B. A database password used by an application

C. A non-sensitive software license title

D. A published user guide

Correct Answer: B. A database password used by an application

Question 6

Why should cloud audit logs be protected from alteration by ordinary administrators?

A. To make applications execute faster

B. To preserve their evidential value and support investigations

C. To eliminate the need for backups

D. To automatically encrypt all network traffic

Correct Answer: B. To preserve their evidential value and support investigations

Question 7

Which activity is part of vulnerability management?

A. Ignoring vulnerabilities with high severity scores

B. Maintaining an asset inventory and verifying remediation

C. Replacing all authentication with passwords

D. Deleting all historical logs

Correct Answer: B. Maintaining an asset inventory and verifying remediation

Question 8

Which principle says that personal data should be collected for specified purposes and not used incompatibly with them?

A. Purpose limitation

B. Network segmentation

C. Envelope encryption

D. Separation of duties

Correct Answer: A. Purpose limitation

Question 9

In the shared responsibility model, which responsibility commonly remains with the customer when using a cloud database service?

A. Maintaining the provider’s physical buildings

B. Replacing the provider’s hardware

C. Configuring identities, permissions, and data protection

D. Operating the provider’s global power supply

Correct Answer: C. Configuring identities, permissions, and data protection

Question 10

Why are tested restoration exercises important for cloud backups?

A. Replication always guarantees recovery

B. They verify that backups are usable and recovery procedures work

C. They eliminate the need for encryption

D. They make all incidents impossible

Correct Answer: B. They verify that backups are usable and recovery procedures work