Cloud Security, Identity and Zero-Trust Architecture

Introduction

Cloud computing changes the location, ownership and operational model of information systems, but it does not eliminate security responsibilities. Instead, security becomes a distributed activity involving the cloud provider, the customer, software suppliers, administrators, developers and users. A provider may secure physical facilities, hardware and foundational services, while the customer remains responsible for identities, data, configurations, applications and—depending on the service model—operating systems and networks.

Cloud security therefore requires more than perimeter firewalls. A secure architecture must establish trustworthy identities, restrict privileges, protect secrets and cryptographic keys, segment networks, harden workloads, detect misuse and continuously assess configuration. Zero-trust architecture provides a useful organising principle: no request is trusted merely because it originates inside a corporate network or cloud virtual network. Access is granted according to verified identity, device and workload context, requested resource, policy and current risk.

This chapter develops a practical and analytical foundation for implementing cloud security, identity and zero trust in postgraduate information-technology environments.

Learning Objectives

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

1. Explain the cloud shared-responsibility model and major cloud-security threats.
2. Design identity and access management using federation, strong authentication and least privilege.
3. Distinguish human, workload and machine identities and select suitable credential mechanisms.
4. Apply secrets management, encryption and key-management controls.
5. Design network-security and workload-protection mechanisms.
6. Apply zero-trust principles to users, devices, workloads, applications and data.
7. Use threat modeling, vulnerability management and cloud security posture management (CSPM).
8. Evaluate security architecture against operational, ethical, regulatory and business requirements.

1. The Cloud Security Context

1.1 Shared responsibility

Responsibility varies by service model. In infrastructure as a service (IaaS), the provider generally operates facilities, physical hosts and core infrastructure; the customer configures virtual networks, guest operating systems, applications, identities and data. In platform as a service (PaaS), the provider additionally manages much of the operating-system and runtime stack. In software as a service (SaaS), the provider operates the application, but the customer still controls users, authorisation, data classification, configuration and often retention settings.

Shared responsibility is not the same as shared accountability. A provider can operate a technically secure service while a customer exposes a storage bucket, grants excessive privileges or fails to rotate a compromised key. Contracts, service descriptions, audit reports and regulatory obligations must therefore be examined together with technical controls.

1.2 Security objectives

The traditional objectives are confidentiality, integrity and availability (CIA). Cloud environments add accountability, privacy, resilience and recoverability. A control should be evaluated against a concrete threat: encryption may reduce disclosure from stolen media, but it does not prevent an authorised user from downloading decrypted data; network segmentation may limit lateral movement, but it does not correct an application injection flaw.

Important cloud threats include:

• stolen credentials, token replay and session hijacking;
• excessive permissions and poorly governed service accounts;
• public or cross-account exposure caused by configuration errors;
• vulnerable images, libraries, containers and managed services;
• insecure application programming interfaces (APIs);
• ransomware, destructive administration and data exfiltration;
• compromised software supply chains;
• inadequate logging, monitoring or incident response;
• provider outage, regional failure and dependence on a single supplier.

2. Identity as the Security Perimeter

2.1 Identity categories

A cloud identity is a security principal to which authentication, authorisation and audit records can be associated. The main categories are:

Separating these categories is important. A human should not share a long-lived password with an application, and an application should not use a permanent administrator key merely because it is convenient.

2.2 Authentication and federation

Authentication establishes who or what is making a request; authorisation determines what that principal may do. Federation allows an organisation to use an identity provider (IdP) to authenticate users to one or more cloud providers or applications. Common concepts include:

• Security Assertion Markup Language (SAML): often used for browser-based enterprise single sign-on.
• OpenID Connect (OIDC): an identity layer over OAuth 2.0, commonly used for modern applications and workload federation.
• OAuth 2.0: an authorisation framework for delegated access; it is not, by itself, a complete authentication protocol.
• Multi-factor authentication (MFA): combines independent factors such as knowledge, possession and inherence. Hardware-backed passkeys and security keys generally provide stronger phishing resistance than one-time codes sent by text message.

Federation reduces password duplication and centralises lifecycle management, but it creates a high-value dependency. The IdP must be strongly protected, administrative roles must be separated, emergency access must be controlled and federation claims must be validated. Trust should be explicit: issuer, audience, signature, validity period and requested scopes must be checked.

2.3 Authorisation models

Role-based access control (RBAC) assigns permissions to roles and roles to principals. It is understandable and effective for stable organisational functions. Attribute-based access control (ABAC) evaluates attributes such as department, data classification, device state, location, time and workload identity. ABAC provides finer context but demands reliable attributes and policy governance. Policy-based access control combines identity, resource, action and environmental conditions in a centrally evaluated policy.

A practical policy can be expressed conceptually as:

Permit a request only when the principal is authenticated, the action is explicitly allowed, the resource belongs to an approved account, the device or workload meets policy, and risk conditions are acceptable.

Deny-by-default is essential. Permissions should be granted to the smallest resource set, for the smallest action set and for the shortest practical duration. Administrative actions should require stronger authentication, approval or a privileged-access-management workflow.

2.4 Least privilege and privilege governance

Least privilege is not simply “few permissions.” It is an operational process comprising role design, access requests, approval, time-limited elevation, monitoring, review and revocation. Permission analysis should include direct grants, group inheritance, resource policies, identity policies and permissions obtained through assumed roles.

Useful measures include the proportion of privileged accounts protected by phishing-resistant MFA, number of unused permissions, age of access reviews and time to revoke departing users. Metrics must be interpreted carefully: reducing permission count is not necessarily beneficial if it creates unsafe shared accounts or obstructs incident response.

3. Secrets, Cryptography and Key Management

3.1 Secrets management

Secrets include passwords, API tokens, private keys, database connection strings, certificates and signing material. They should not be embedded in source code, container images, chat messages, build logs or infrastructure templates. A secrets-management service should provide encrypted storage, access policy, versioning, audit trails, controlled retrieval and rotation.

Applications should retrieve secrets at runtime using workload identity. Prefer short-lived credentials and dynamic secrets, such as a database account created for a limited period. Rotation must be designed as an application capability: if a service cannot accept a new credential without downtime, rotation will be delayed and risk will accumulate. Revocation, emergency replacement and recovery must be tested.

3.2 Encryption states

Encryption should be considered in three states:

• At rest: databases, object stores, disks, snapshots and backups.
• In transit: client-to-service, service-to-service and administrative connections, usually using modern TLS configurations.
• In use: data while processed in memory; confidential-computing technologies can reduce exposure in selected workloads but do not remove application or identity risks.

Encryption is not a substitute for authorisation. A stolen application identity may legitimately obtain plaintext from a service. Data classification should determine where encryption, tokenisation, masking, retention and geographic restrictions are required.

3.3 Key-management architecture

A key-management system (KMS) generates, stores, uses and audits cryptographic keys. Hardware security modules may protect high-value key material. A mature design separates key administrators from data users, restricts key usage by purpose, records every use and defines rotation, backup, destruction and recovery procedures.

Envelope encryption is widely used. A data-encryption key (DEK) encrypts the data; a key-encryption key (KEK), held by a KMS, encrypts the DEK. The encrypted DEK is stored with the ciphertext, while the KEK remains under central control. This reduces the amount of data directly processed by the KMS and allows controlled rewrapping of DEKs.

The confidentiality benefit of encryption depends on the threat model. If an attacker obtains both ciphertext and permission to call the decryption service, key separation alone is insufficient. Strong authorisation, monitoring and workload isolation remain necessary.

4. Network Security and Workload Protection

4.1 Segmentation and connectivity

Cloud networks should be designed around trust boundaries, not merely IP ranges. Separate production, development, security tooling and management functions. Use private service endpoints where feasible, restrictive security groups or network policies, controlled egress, route inspection and central logging. Internet-facing components should normally be placed behind load balancers, web-application firewalls, DDoS protection and hardened ingress controls.

Microsegmentation limits lateral movement by applying policy between workloads. However, excessive segmentation can create complexity and informal bypasses. Segmentation decisions should follow data flows, threat models and operational ownership.

4.2 Workload protection

Workload security begins before deployment. Use approved base images, signed artifacts, dependency scanning, infrastructure-as-code review and reproducible builds. At runtime, apply minimal operating-system packages, non-root execution, immutable or replaceable instances, host and container monitoring, resource limits and admission policies.

Containers do not provide automatic isolation equivalent to separate physical hosts. The container runtime, orchestration control plane, image registry, node operating system and workload configuration all require protection. Kubernetes environments particularly require restricted service-account permissions, network policies, protected secrets, admission control and audit logging.

Serverless functions require least-privilege execution roles, dependency control, event-source validation, concurrency limits and protection against excessive permissions in shared execution environments.

5. Zero-Trust Architecture

Zero trust is an architectural approach, not a product. Its central proposition is to make access decisions based on verified and continuously evaluated conditions rather than network location. Widely used zero-trust guidance identifies principles such as:

1. Verify explicitly.
2. Use least-privilege access.
3. Assume breach.
4. Protect resources rather than trusting network segments.
5. Continuously observe, evaluate and improve.

A zero-trust request can be represented conceptually as a policy decision involving subject, device, workload, resource, action, context and risk. The policy engine evaluates these inputs; a policy enforcement point permits, denies or limits the session. Telemetry from identity, endpoint, network, application and data systems supports reassessment.

Figure: A zero-trust access request is evaluated using identity, context and resource policy, with continuous reassessment.

Zero trust does not mean denying all access, eliminating firewalls or requiring a new product for every control. It means making trust explicit, narrow, observable and revocable. Legacy systems may require compensating controls such as gateways, bastion services, application proxies or network isolation while modernisation proceeds.

6. Threat Modeling, Vulnerability Management and CSPM

6.1 Threat modeling

Threat modeling is a structured way to anticipate abuse before deployment. A team identifies assets, trust boundaries, actors, entry points, assumptions and security objectives. It then considers threats such as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The resulting mitigations are linked to owners and verification tests.

A cloud threat model should include control-plane APIs, cross-account roles, metadata services, CI/CD pipelines, registries, backup systems, managed-service configuration and provider dependencies. It should be updated when architecture, data classification or attacker capability changes.

6.2 Vulnerability management

Vulnerability management includes asset inventory, scanning, prioritisation, remediation, exception handling and verification. A scanner's severity score is not the same as organisational risk. Prioritisation should consider exploitability, exposure, asset importance, compensating controls and evidence of active exploitation.

Patch management must address operating systems, containers, libraries, infrastructure modules, firmware and managed-service configuration. A risk-based service-level objective may require internet-facing critical vulnerabilities to be fixed faster than an equivalent flaw in an isolated development system. Exceptions need expiry dates and accountable approval.

6.3 Cloud security posture management

CSPM continuously evaluates cloud accounts and resources against desired configurations and policy. Typical checks include public storage exposure, unrestricted management ports, disabled logging, weak encryption settings, excessive permissions, unprotected backups and drift from approved infrastructure-as-code.

CSPM is valuable but imperfect. It may generate false positives, overlook application logic, depend on incomplete provider APIs or encourage checkbox compliance. Findings should be risk-ranked, assigned to owners, automatically remediated only when safe and validated through attack simulation or control testing.

7. Monitoring, Response and Resilience

Security logs should cover identity events, privileged actions, policy decisions, network flows, data access, configuration changes, workload execution and key use. Logs require time synchronisation, integrity protection, retention appropriate to legal and investigative needs, access restrictions and privacy controls.

Detection engineering should focus on behaviour rather than isolated alerts. Examples include impossible travel, unusual role assumption, mass object reads, unexpected key use, disabled logging, creation of public endpoints and abnormal data egress. Detection must be tested against realistic attack paths.

Incident response typically includes preparation, detection and analysis, containment, eradication, recovery and lessons learned. Cloud-specific response may involve disabling sessions, revoking tokens, isolating workloads, preserving snapshots, restricting egress and coordinating with the provider. Business continuity requires tested backups, restoration procedures, alternate regions or providers where justified, and clearly defined recovery objectives.

8. Illustrative Case: Securing a Multi-Cloud Health Analytics Platform

Background

This illustrative case concerns MedData Analytics, a fictional organisation that processes hospital data in two cloud providers. Analysts use a SaaS dashboard; data pipelines run in containers; a machine-learning service accesses de-identified datasets. The organisation must meet contractual privacy obligations and demonstrate access accountability.

Problem

An audit finds permanent administrator keys in a code repository, broad analyst permissions, a development storage bucket accessible from the internet, inconsistent logging and direct administrative access from unmanaged laptops. The organisation has deployed network firewalls but cannot explain which identities accessed sensitive objects or why.

Analysis

The primary risk is not one missing firewall rule. It is a combination of identity concentration, long-lived credentials, weak environment separation, configuration drift and inadequate evidence. Threat modeling identifies repository compromise, credential replay, cross-environment movement, accidental disclosure and malicious insider activity as plausible scenarios.

Approach and solution

MedData establishes a central IdP with phishing-resistant MFA and federation to both clouds. Human administrators receive separate standard and privileged identities. Privileged access is approved just in time and recorded. Workloads use federated, short-lived identities rather than embedded keys.

Sensitive data is classified and encrypted with customer-controlled key policies. Analysts receive role-based access to approved views rather than raw tables. The development bucket is made private, and private service endpoints restrict data paths. Container images are signed, scanned and admitted only when they meet policy. Central logs capture identity, object access, role changes, key use and network flows.

A CSPM service detects public exposure and configuration drift; infrastructure-as-code pipelines prevent recurrence. Endpoint posture checks block unmanaged devices from administrative access. Response playbooks cover token revocation, workload isolation, key disablement and forensic preservation.

Outcome

The organisation reduces standing privilege, improves attribution and gains evidence for audits. It also discovers that some analytics jobs depend on broad permissions; these are redesigned into separate roles rather than simply denied. Recovery exercises reveal that encrypted backups cannot be restored without access to the key-management account, leading to a tested break-glass process with independent approval.

Learning points

1. Zero trust requires identity, device, workload and data controls together.
2. Technical controls must be connected to operational processes and evidence.
3. Least privilege is iterative: real usage analysis is needed after initial policy design.
4. Key recovery and emergency access deserve the same design attention as encryption.
5. Automated posture checks prevent recurrence but do not replace threat modeling.

9. Governance, Ethics and Contemporary Developments

Security governance should define ownership, policy exceptions, audit rights, data residency, provider notification duties, retention, deletion and subcontractor controls. Regulatory requirements vary by jurisdiction and sector; therefore, technical teams should map controls to applicable privacy, critical-infrastructure, financial, health and breach-notification obligations rather than assuming one certification proves compliance.

Privacy and security can conflict. Extensive monitoring may improve detection while creating surveillance risks. Collect only necessary telemetry, restrict access, define retention and explain legitimate purposes. Automated risk scoring should be transparent enough to challenge erroneous decisions, especially when it affects employees or customers.

Current developments include passwordless authentication, workload identity federation, confidential computing, software bills of materials, policy-as-code, identity threat detection, secure access service edge architectures and AI-assisted security operations. AI can help correlate alerts, summarise incidents and identify anomalous behaviour, but generated recommendations require validation. An AI system may expose sensitive logs, reproduce bias or confidently propose destructive remediation. Human approval, data minimisation and testing remain essential.

10. Best-Practice Design Principles

A defensible cloud-security programme should:

• inventory identities, assets, data flows and dependencies;
• enforce MFA, federation and separate privileged identities;
• use deny-by-default, least privilege and time-limited elevation;
• replace embedded secrets with managed, short-lived credentials;
• encrypt sensitive data and govern keys independently;
• segment environments and control ingress and egress;
• secure source code, dependencies, images, pipelines and runtime workloads;
• centralise tamper-resistant logs and test detections;
• continuously assess posture and remediate configuration drift;
• conduct threat modeling before major changes;
• test incident response, backup restoration and break-glass access;
• measure outcomes, not merely tool deployment or policy completion.

Challenges and Limitations

Cloud security is constrained by complexity, skill shortages, provider differences, legacy systems and competing availability requirements. A highly restrictive policy can reduce productivity and encourage circumvention. Centralising identity and logging creates concentration risk. Multi-cloud strategies may improve resilience or bargaining power but can multiply configuration and governance problems. Encryption can complicate search, analytics and lawful recovery. Zero trust is also not a guarantee against compromise: valid identities can be abused, policy engines can be misconfigured and software can contain unknown vulnerabilities.

The appropriate objective is not perfect prevention. It is controlled exposure: reduce attack surface, detect misuse quickly, limit blast radius, preserve evidence and recover reliably.

Chapter Summary

Cloud security is a shared-responsibility discipline in which providers and customers divide operational duties but remain jointly concerned with risk. Identity is the principal security perimeter: federation, strong authentication, workload identity, least privilege and lifecycle governance are foundational. Secrets should be centrally managed and preferably short-lived. Encryption protects data at rest, in transit and, in selected cases, in use; key-management design must address separation of duties, rotation, recovery and auditability.

Network segmentation, workload hardening, secure software supply chains and runtime controls reduce attack surface. Zero-trust architecture replaces implicit network trust with continuous evaluation of identity, device, workload, resource, action and context. Threat modeling, vulnerability management and CSPM provide complementary preventive and detective capabilities, while monitoring, incident response and tested recovery limit impact. Governance must integrate security, privacy, regulation, ethics and business resilience.

Key Terms

Identity: A principal that can be authenticated, authorised and audited.

Authentication: Verification of a subject’s claimed identity.

Authorisation: Determination of actions a verified subject may perform.

Federation: Use of an external identity provider to authenticate users or workloads to a relying service.

MFA: Authentication using two or more independent factors.

RBAC: Access control based on roles and assigned permissions.

ABAC: Access control based on attributes and policy conditions.

Least privilege: Granting only the minimum necessary permissions for the required time.

Workload identity: An identity assigned to software or an executing service.

Secret: Sensitive authentication or cryptographic material requiring controlled storage.

Encryption: Transformation of readable data into ciphertext using a cryptographic process.

KMS: A service for generating, protecting, using and auditing cryptographic keys.

Envelope encryption: Encrypting data with a DEK and protecting that DEK with a KEK.

Zero trust: An architecture that avoids implicit trust and continuously evaluates access.

Microsegmentation: Fine-grained policy enforcement between workloads or services.

Threat modeling: Structured identification and treatment of threats during system design.

Vulnerability management: Discovery, prioritisation, remediation and verification of weaknesses.

CSPM: Continuous assessment of cloud configurations against security policies.

Break-glass access: Exceptional emergency access subject to strong control and auditing.

Review Questions

Short Answer Questions

1. Explain the difference between authentication and authorisation.
2. What is the purpose of cloud federation?
3. State two advantages of short-lived workload credentials.
4. Distinguish encryption at rest from encryption in transit.
5. Why is CSPM insufficient as a complete security strategy?

Long Answer Questions

1. Compare RBAC and ABAC, including their governance advantages and limitations.
2. Explain how envelope encryption supports scalable cloud key management.
3. Describe a zero-trust access decision and the evidence it should evaluate.
4. Discuss how threat modeling and vulnerability management complement one another.
5. Evaluate the shared-responsibility model across IaaS, PaaS and SaaS.

Analytical / Application Questions

1. Design an identity and access architecture for a multi-cloud organisation with employees, contractors and containerised workloads. Justify authentication, federation and privilege controls.
2. A company discovers a public storage bucket containing sensitive data and a permanent API key in a repository. Develop an incident-response and long-term prevention plan.
3. Critically evaluate whether network microsegmentation alone can achieve zero trust. Identify the additional controls required and explain their interaction.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorisation?

A. Authentication grants permissions, while authorisation verifies identity.

B. Authentication verifies identity, while authorisation determines permitted actions.

C. Authentication encrypts data, while authorisation rotates keys.

D. Authentication segments networks, while authorisation scans vulnerabilities.

Correct Answer: B. Authentication verifies identity, while authorisation determines permitted actions.

Question 2

Which credential is generally most appropriate for a cloud workload that needs temporary access to an object store?

A. A permanent account-owner access key embedded in the image

B. A shared administrator password stored in source code

C. A short-lived workload identity with a narrowly scoped role

D. An unaudited credential copied to every application host

Correct Answer: C. A short-lived workload identity with a narrowly scoped role

Question 3

What is the principal purpose of envelope encryption?

A. To eliminate the need for authorisation

B. To encrypt data with a DEK and protect that DEK with a KEK

C. To make all network traffic anonymous

D. To replace backups with key rotation

Correct Answer: B. To encrypt data with a DEK and protect that DEK with a KEK

Question 4

Which action is most consistent with zero-trust architecture?

A. Allowing all traffic from the corporate network without further checks

B. Trusting a workload because it runs inside a private subnet

C. Evaluating identity, device or workload context, resource and requested action

D. Removing all firewalls because identity controls are sufficient

Correct Answer: C. Evaluating identity, device or workload context, resource and requested action

Question 5

Which control most directly reduces the risk of secrets appearing in application repositories?

A. Storing secrets in a managed secrets service and retrieving them at runtime

B. Renaming the secret variables before committing them

C. Compressing the repository before publication

D. Granting every developer administrator access

Correct Answer: A. Storing secrets in a managed secrets service and retrieving them at runtime

Question 6

What is a major limitation of CSPM tools?

A. They cannot detect any configuration errors

B. They replace the need for identity management

C. They may miss application-logic flaws and produce false positives

D. They function only on physical servers

Correct Answer: C. They may miss application-logic flaws and produce false positives

Question 7

Which practice best supports least privilege?

A. Using one shared administrator account for operational simplicity

B. Granting permanent broad access to avoid service interruptions

C. Providing narrowly scoped, time-limited elevation with review and logging

D. Disabling access reviews after initial deployment

Correct Answer: C. Providing narrowly scoped, time-limited elevation with review and logging

Question 8

Which item should be included in a cloud threat model?

A. Only the provider’s physical buildings

B. Control-plane APIs, trust boundaries and CI/CD pipelines

C. Only the colour scheme of the management console

D. Only threats that have already caused an incident

Correct Answer: B. Control-plane APIs, trust boundaries and CI/CD pipelines

Question 9

Which statement about network segmentation is correct?

A. Segmentation alone establishes zero trust

B. Segmentation can limit lateral movement but must be combined with identity and workload controls

C. Segmentation removes the need for logging

D. Segmentation guarantees that authorised identities cannot be abused

Correct Answer: B. Segmentation can limit lateral movement but must be combined with identity and workload controls

Question 10

Which is an example of a workload identity?

A. A developer’s job title

B. A physical data-centre badge

C. An identity assigned to a serverless function or container service

D. A storage bucket’s encryption algorithm

Correct Answer: C. An identity assigned to a serverless function or container service