Identity, Security, and Zero-Trust Deployment

Introduction

Cloud infrastructure changes the location, ownership, and operation of computing resources, but it does not remove the need for security. Instead, it changes how security is designed. A traditional data centre often relied on a protected network perimeter, manually managed servers, and relatively stable user populations. Cloud environments are dynamic, distributed, programmable, and accessed by employees, applications, contractors, devices, and automated services from many locations.

Security in this environment depends less on trusting a network location and more on continuously verifying identity, device condition, requested action, resource sensitivity, and environmental risk. This approach is commonly described as zero trust. Identity and access management (IAM), encryption, secrets management, network segmentation, vulnerability controls, monitoring, and governance are the principal mechanisms through which zero trust is implemented.

The cloud provider and customer share responsibility for security. The provider generally secures the physical facilities, underlying hardware, and core managed services. The customer remains responsible for appropriate configuration, identities, data, applications, operating systems where applicable, and access decisions. The exact division varies according to whether a service is infrastructure, platform, or software as a service.

Learning Objectives

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

1. Explain IAM concepts, authentication, authorization, federation, and role-based access control.
2. Apply least privilege and separation of duties to cloud environments.
3. Distinguish secrets management from key management and select suitable controls.
4. Explain encryption at rest, in transit, and in use, including key-lifecycle concerns.
5. Design basic network segmentation and vulnerability-management controls.
6. Apply zero-trust principles under the shared-responsibility model.
7. Evaluate security decisions using practical, ethical, governance, and operational criteria.

1. Security as a Cloud Design Requirement

Security should be designed before deployment rather than added after an incident. A useful security design considers five properties:

• Confidentiality: only authorized subjects can view information.
• Integrity: information and systems cannot be changed without authorization.
• Availability: authorized users can access services when required.
• Authenticity: users, services, and messages are genuine.
• Accountability: actions can be attributed to identities and investigated.

These properties can conflict. Strong encryption may increase computational or operational complexity. Extensive logging may improve accountability but create privacy and storage obligations. Aggressive network isolation may reduce attack paths but complicate administration. Professional security engineering therefore involves risk-based decisions rather than applying every control indiscriminately.

A basic risk model is:

Likelihood represents the estimated chance that a harmful event will occur during a specified period, while impact represents the magnitude of resulting harm. The expression is a prioritisation model, not a precise physical law. Both terms must be defined consistently; impact may include financial loss, service interruption, legal consequences, safety effects, and reputational damage. Risk assessments should also consider uncertainty, dependencies, and the effectiveness of existing controls.

2. Identity and Access Management

2.1 Core terminology

An IAM system controls which subjects can perform which actions on which resources under specified conditions. A subject may be a human user, workload, device, group, or external organization. An action may be read, create, modify, delete, approve, invoke, or administer. A resource may be a database, object, virtual machine, secret, network, or application programming interface.

Authentication answers the question, “Who or what is requesting access?” Authorization answers, “What is that authenticated subject permitted to do?” Accounting or auditing records what occurred. These functions must not be confused: successful authentication does not imply unrestricted authorization.

Important identity concepts include:

• Principal: an identity recognized by a platform.
• Credential: evidence used to authenticate a principal, such as a password, certificate, or token.
• Policy: a formal statement of permitted or denied actions.
• Role: a set of permissions that can be assumed or assigned.
• Entitlement: a granted capability or access right.
• Session: a bounded period during which authenticated access is used.
• Service identity: a non-human identity used by an application or workload.

2.2 Authentication

Password-only authentication is vulnerable to phishing, password reuse, credential stuffing, and database compromise. Modern cloud deployments should prefer phishing-resistant or multi-factor authentication (MFA), particularly for administrators and high-value operations. MFA combines independent factors such as knowledge, possession, and inherence. A second factor should not merely be another password or an easily intercepted one-time code when stronger options, such as hardware security keys, are available.

Authentication controls should include:

• centralized identity where practical;
• MFA for privileged and sensitive access;
• short-lived credentials and sessions;
• conditional access based on device, location, risk, or resource;
• prompt revocation when employment or responsibility ends;
• protection against automated credential attacks;
• strong recovery processes that do not undermine MFA.

Human identities and workload identities should be managed differently. A developer may use federated access through an organizational identity provider, whereas a workload should use a service account, managed identity, or workload identity federation rather than a developer’s long-lived access key.

2.3 Authorization models

Discretionary access control allows resource owners to grant access. It is flexible but can produce uncontrolled sharing. Mandatory access control applies centrally defined classifications and rules. It is useful in highly regulated environments but may be complex. Role-based access control (RBAC) assigns permissions to roles and users or workloads to roles. RBAC simplifies administration when organizational duties are stable. Attribute-based access control (ABAC) evaluates attributes such as department, data classification, device state, time, or geographic region. ABAC supports contextual decisions but requires reliable attributes and careful policy testing.

A practical cloud design often combines RBAC and ABAC. For example, a data analyst may have an analyst role, but a policy may restrict that role to datasets tagged as non-production and to devices meeting defined security requirements.

2.4 Least privilege and separation of duties

Least privilege means granting only the permissions necessary for a subject to perform an approved task, for only as long as necessary. It has four dimensions:

1. Scope: restrict the resources and actions.
2. Time: use temporary access and expiration.
3. Context: apply conditions such as device posture or network path.
4. Authority: avoid granting administrative permissions when a narrower role is sufficient.

Least privilege is not the same as granting no access. Excessive restriction can cause unsafe workarounds, shared accounts, and operational failures. Permissions should therefore be reviewed against actual task requirements and tested in non-production environments.

Separation of duties prevents one person or process from completing a sensitive transaction alone. For example, one engineer may create an infrastructure change, while another approves it and an automated pipeline deploys it. Break-glass accounts may be necessary for emergencies, but their use should require strong authentication, monitoring, justification, and post-event review.

A permission-review process can classify permissions as:

• required and actively used;
• required but rarely used;
• unnecessary;
• excessive or dangerous;
• unknown and requiring investigation.

Unused permissions should not be removed automatically without considering service dependencies, but they should be investigated and reduced where possible.

3. Federation and Lifecycle Management

Federation allows one identity provider to authenticate a user for another service. Instead of creating separate passwords in every cloud platform, an organization can use a central provider and protocols such as Security Assertion Markup Language, OpenID Connect, or OAuth 2.0-based flows. Federation improves central control, supports single sign-on, and enables rapid disabling of a user. It does not automatically make access secure: poor claims, excessive role mappings, weak authentication, or incorrect token validation can still create serious exposure.

A federated design should address:

• trusted issuers and audience validation;
• token lifetime and replay protection;
• accurate mapping of groups or claims to roles;
• MFA and conditional-access requirements;
• emergency access if the identity provider is unavailable;
• joiner, mover, and leaver processes;
• regular review of external identities and guests.

Workload identity federation enables a build system or external workload to obtain short-lived cloud credentials based on an attested identity rather than storing a permanent secret. This is particularly valuable for CI/CD systems. Trust relationships must be narrowly scoped: a token from one repository or environment should not automatically administer every production resource.

4. Secrets and Key Management

4.1 Secrets management

A secret is sensitive data used to authenticate or authorize access. Examples include database passwords, API tokens, private keys, signing credentials, and connection strings. Secrets should not be embedded in source code, container images, machine images, ticket systems, or general-purpose configuration files.

A secrets-management service should provide:

• encrypted storage;
• controlled retrieval based on identity and policy;
• versioning and rotation;
• audit records;
• separation between secret administrators and users;
• automated injection into applications where possible;
• emergency revocation.

Rotation is not merely changing a value. A complete rotation process creates or obtains a new credential, updates dependent consumers, verifies operation, revokes the old credential, and records the event. Applications should tolerate overlapping credentials during controlled rotation to avoid outages.

4.2 Cryptographic key management

A cryptographic key is used by an algorithm to encrypt, decrypt, authenticate, or sign data. Key management includes generation, storage, distribution, use, rotation, backup, recovery, revocation, and destruction. Keys should be protected in a key-management service or hardware security module when the risk and regulatory context justify it.

Important distinctions include:

• Data-encryption keys (DEKs): encrypt actual data.
• Key-encryption keys (KEKs): encrypt or wrap DEKs.
• Root or master keys: higher-level keys used to protect other keys.
• Signing keys: establish authenticity and integrity rather than confidentiality.

Envelope encryption commonly uses a DEK for data and a KEK to protect the DEK. This reduces the need to use a master key directly for large amounts of data and supports controlled key rotation. Destroying a key can make protected data unrecoverable, so key destruction requires authorization, retention analysis, and tested recovery procedures.

4.3 Cryptographic controls

Encryption in transit protects data moving across networks, commonly through protocols such as TLS. Encryption at rest protects stored data, backups, snapshots, and disks. Encryption in use seeks to protect data while being processed, for example through confidential-computing technologies; its availability and suitability depend on workload and platform support.

Encryption does not solve every security problem. It does not prevent an authorized but malicious user from reading decrypted data, eliminate insecure endpoints, or guarantee correct key access policies. Integrity and authenticity must also be considered, often through authenticated encryption, digital signatures, certificates, or message authentication codes.

5. Network Segmentation and Workload Protection

A cloud network should be designed around communication requirements rather than assumed trust. Segmentation divides workloads into zones with controlled flows. Common zones include public ingress, application services, data services, administration, development, testing, and production.

Controls may include:

• private subnets or equivalent network boundaries;
• security groups or workload firewalls;
• network firewalls and web application firewalls;
• routing controls and egress filtering;
• private service endpoints;
• administrative access through controlled bastions or identity-aware proxies;
• separate accounts, subscriptions, or projects for environments;
• microsegmentation between services.

Segmentation is effective only when rules are explicit, reviewed, and monitored. A network boundary is not a substitute for IAM. An attacker who compromises an application should not gain access merely because the application is inside a “trusted” network. Conversely, a strong IAM policy can be undermined if unrestricted egress allows data exfiltration.

A useful design method is to document, for each service:

1. Which identities may invoke it?
2. Which ports and protocols are required?
3. Which destinations are legitimate?
4. Which data may cross each boundary?
5. How are flows logged and investigated?

Default-deny rules are generally preferable for sensitive zones, followed by narrowly documented exceptions. Rules should be tested as code where possible, because manually edited firewall configurations drift over time.

6. Vulnerability, Configuration, and Patch Management

Vulnerability management is a continuous process rather than a single scan. It includes asset discovery, vulnerability identification, risk assessment, remediation, validation, and reporting. Cloud environments require discovery of short-lived assets, images, serverless functions, managed services, dependencies, identities, and infrastructure-as-code definitions.

A sound programme combines:

• secure baseline configurations;
• operating-system and application patching;
• container-image and dependency scanning;
• infrastructure-as-code analysis;
• cloud-security posture management;
• penetration testing where authorized;
• runtime detection and response;
• exception management with expiry dates.

Severity scores are useful but incomplete. A moderate vulnerability on an internet-facing, privileged service may deserve faster action than a high-scoring issue on an isolated, non-production system. Prioritization should consider exploitability, exposure, asset value, compensating controls, and evidence of active exploitation.

Patching must be operationally safe. Organizations should maintain inventories, test updates, use staged deployment, retain rollback options, and monitor service behavior. Unsupported software should be upgraded, isolated, replaced, or formally accepted as a risk for a limited period.

7. Zero-Trust Deployment

Zero trust is a security model based on the principle that no user, device, workload, or network location is automatically trusted. It does not mean that trust is impossible; rather, access decisions are continually evaluated and explicitly justified.

Core principles include:

• verify explicitly using identity and contextual signals;
• apply least privilege;
• assume breach and limit blast radius;
• protect resources rather than relying on a perimeter;
• monitor continuously and improve through feedback.

A zero-trust request can be represented conceptually as:

Here, f is the policy-decision process. Identity identifies the subject; device represents posture and health; resource and action describe what is requested; context may include time, location, network, and workload state; policy defines organizational requirements; and risk represents current evidence. This is a conceptual model, not a universal numerical equation.

Zero-trust architecture often separates:

• a policy engine, which evaluates signals and rules;
• a policy administrator, which communicates the decision;
• a policy enforcement point, which permits, blocks, or limits the request.

Implementation should be incremental. An organization can begin by inventorying identities and resources, enforcing MFA for privileged access, removing standing administrative privileges, segmenting production, centralizing logs, and protecting high-value applications with identity-aware access. It can then introduce device posture checks, workload identity, automated policy analysis, and adaptive responses.

Zero trust is not identical to “put everything behind a VPN.” A VPN may authenticate a user to a network, but it may still grant broad lateral access. Zero-trust access generally authorizes a specific application or resource and evaluates the request continuously.

8. Shared Responsibility and Governance

The shared-responsibility model must be documented for every service. In a typical infrastructure service, the provider secures facilities, hardware, and core virtualization, while the customer secures guest operating systems, applications, identities, data, and network configuration. In a managed database, the provider may secure more of the operating system and database platform, but the customer still controls data classification, users, permissions, encryption settings, and secure queries. In software as a service, the customer remains responsible for users, configuration, data, sharing, and governance even though the provider operates the application.

A responsibility matrix should identify:

The matrix is illustrative; contracts and service documentation control the actual allocation. Security governance should also address data protection laws, contractual obligations, records retention, breach notification, audit rights, data residency, accessibility, and ethical use of personal information. Least privilege and monitoring should not be used to justify unnecessary surveillance. Collection of security data should be proportionate, protected, and limited to legitimate purposes.

9. Monitoring, Detection, and Incident Response

Preventive controls are insufficient because compromise cannot always be avoided. Security logs should record authentication events, privilege changes, policy decisions, network flows where appropriate, key use, secret access, configuration changes, and administrative actions. Logs should be time-synchronized, protected from alteration, retained according to risk and legal requirements, and made useful to investigators.

A practical incident process includes:

1. Preparation: roles, playbooks, contacts, backups, and exercises.
2. Detection and analysis: validate alerts, establish scope, and preserve evidence.
3. Containment: limit access, isolate workloads, revoke credentials, or block flows.
4. Eradication: remove malicious persistence and correct the underlying weakness.
5. Recovery: restore services carefully and monitor for recurrence.
6. Lessons learned: improve architecture, policy, training, and response procedures.

Automation is valuable for predictable actions such as disabling a compromised token or isolating a workload. However, automated response must be tested to prevent cascading outages and should preserve human oversight for high-impact decisions.

10. Illustrative Case: Securing a Cloud Learning Platform

Background

A fictional college operates a cloud-based learning platform. Students, lecturers, administrators, and external examiners access applications from personal and institutional devices. The platform contains grades, attendance records, course materials, and payment-related information.

Problem

An audit finds shared administrator accounts, long-lived API keys in a deployment repository, a flat production network, excessive student-service permissions, and incomplete logging. A compromised developer credential could potentially access student records and modify grades.

Analysis

The principal risks are credential compromise, unauthorized privilege escalation, lateral movement, data disclosure, and loss of integrity. The grade-management function is especially sensitive because unauthorized changes may harm students and undermine institutional trust. The organization also has obligations concerning privacy, retention, access requests, and incident reporting.

Approach and solution

The college federates staff access through its institutional identity provider and requires MFA, using phishing-resistant factors for administrators. Student access is separated from staff administration. Individual administrative identities replace shared accounts, and privileged roles are granted temporarily through an approval workflow.

The deployment pipeline receives short-lived workload credentials through federation rather than storing permanent keys. Database passwords are placed in a managed secrets service, with automated rotation and audited retrieval. Encryption is enabled for stored data and backups, while TLS protects service communication. Key administrators are separated from application administrators.

The production environment is placed in a separate cloud account or project. Public ingress reaches only the web tier. Application services use private connectivity to data services, and database access is limited to specific service identities and ports. Egress is restricted to documented destinations. Infrastructure and IAM policies are reviewed through code before deployment.

Centralized logs record sign-ins, privilege elevation, grade changes, secret retrieval, and administrative configuration. Alerts are generated for impossible-travel patterns, unusual data downloads, new privileged assignments, and changes outside approved deployment windows. Backups are encrypted, access-controlled, and periodically restored in testing.

Outcome

The revised design reduces standing privilege, makes actions attributable to individuals, limits the blast radius of a compromised service, and improves the institution’s ability to investigate incidents. It does not eliminate risk: phishing, software defects, misconfigured policies, and insider misuse remain possible. Continuous review and testing are therefore retained.

Learning points

1. Identity improvements must be combined with network and application controls.
2. Short-lived workload credentials are safer than permanent repository keys.
3. Sensitive business actions require strong authorization and auditability.
4. Segmentation reduces lateral movement but does not replace least privilege.
5. Security controls must be tested for both protection and operational availability.

11. Practical Design and Assessment Checklist

Before approving a cloud deployment, ask:

• Are all human and workload identities known and uniquely attributable?
• Is MFA enforced for privileged access?
• Are permissions narrowly scoped, time-limited, and reviewed?
• Can staff federate access without sharing passwords?
• Are secrets absent from code, images, and ordinary logs?
• Are key ownership, rotation, recovery, and destruction defined?
• Is sensitive data encrypted in transit and at rest?
• Are production, development, and administration segmented?
• Are inbound and outbound flows justified and monitored?
• Are assets, dependencies, images, and configurations scanned?
• Are patches prioritized by exposure and business impact?
• Are logs protected, retained, and connected to response procedures?
• Does the responsibility matrix identify both provider and customer duties?
• Have recovery, revocation, and incident-response procedures been exercised?

12. Challenges and Limitations

Cloud security programmes face several recurring difficulties. Excessive policy complexity can create contradictory rules and access failures. Excessive centralization can create a single point of failure or an overly powerful administrator. Multi-cloud environments introduce inconsistent identity models, logging formats, and control capabilities. Legacy applications may not support federation, short-lived credentials, or modern encryption.

Zero trust can also be misunderstood as a product rather than an operating model. Buying an identity-aware proxy or security platform does not establish zero trust unless identities, policies, assets, monitoring, and processes are properly designed. Continuous verification can affect performance and user experience, while device and behavioral signals may create privacy concerns or produce false positives.

AI-assisted security tools can summarize alerts, identify unusual behavior, and help analyze configuration. They should not be treated as authoritative decision-makers without validation. Training data, prompt manipulation, hallucinated explanations, biased risk scoring, and exposure of sensitive logs are significant concerns. Human review, access controls, model governance, and evidence-based testing remain necessary.

Chapter Summary

Cloud security is a system of interacting controls rather than a single product. IAM establishes identities, authentication verifies them, and authorization limits their actions. Federation reduces duplicate credentials and supports centralized lifecycle management, while workload identity federation avoids long-lived automation keys. Least privilege, separation of duties, temporary access, and regular entitlement review reduce the consequences of compromise.

Secrets management protects credentials used by applications; key management governs cryptographic keys throughout their lifecycle. Encryption in transit, at rest, and sometimes in use protects data, but effective policies and access controls remain essential. Network segmentation, egress control, secure configuration, patching, scanning, and monitoring limit attack paths and improve detection.

Zero trust replaces implicit network trust with explicit, contextual, and continuously evaluated access decisions. It is implemented progressively through identity, device, resource, policy, and monitoring capabilities. Finally, the shared-responsibility model requires customers to understand exactly which security tasks remain theirs. Ethical governance, privacy, resilience, and operational practicality must guide every deployment decision.

Key Terms

IAM: The discipline and technology used to manage identities and access to resources.

Authentication: Verification of the identity of a user, device, or workload.

Authorization: Determination of which actions an authenticated subject may perform.

Federation: Trust between identity systems that enables one provider to authenticate users for another service.

MFA: Authentication requiring two or more independent evidence factors.

Least privilege: Granting only the minimum necessary access for the required task and period.

RBAC: Access control based on organizational roles and their permissions.

ABAC: Access control based on attributes, context, and policy.

Workload identity: A non-human identity assigned to an application, service, or automated process.

Secret: Sensitive authentication or authorization data such as a password or token.

Key management: Generation, protection, use, rotation, recovery, revocation, and destruction of cryptographic keys.

Envelope encryption: Protecting data with a data-encryption key that is itself protected by another key.

Encryption at rest: Protection of stored data using cryptographic mechanisms.

Network segmentation: Dividing a network or environment into controlled communication zones.

Vulnerability management: The process of discovering, prioritizing, remediating, and validating security weaknesses.

Zero trust: A security model that avoids implicit trust and continuously evaluates access.

Policy enforcement point: A component that permits, blocks, or limits a requested action.

Shared responsibility: The division of security duties between a cloud provider and its customer.

Break-glass account: A tightly controlled emergency account used when normal administrative access is unavailable.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What is the purpose of workload identity federation?
3. State two dimensions of least privilege.
4. Distinguish a secret from a cryptographic key.
5. Why does network segmentation not replace IAM?

Long Answer Questions

1. Explain how RBAC and ABAC can be combined in a cloud deployment.
2. Describe the lifecycle of a secret and the controls required for safe rotation.
3. Explain encryption at rest, in transit, and in use, including their limitations.
4. Discuss the shared-responsibility model for infrastructure, platform, and software services.
5. Explain how an organization can progressively implement zero-trust deployment.

Analytical / Application Questions

1. A deployment pipeline stores a permanent cloud administrator key in a public code repository. Analyze the risks and propose a replacement design.
2. A database is located in a private subnet, but every application identity can query it. Evaluate whether the design is secure and recommend improvements.
3. During an incident, an employee’s account is used from an unfamiliar device to download large volumes of sensitive data. Design an immediate response and identify longer-term zero-trust controls.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication verifies identity; authorization determines permitted actions.

B. Authentication encrypts data; authorization decrypts data.

C. Authentication segments networks; authorization patches systems.

D. Authentication stores logs; authorization deletes logs.

Correct Answer: A. Authentication verifies identity; authorization determines permitted actions.

Question 2

Which practice most directly applies least privilege to a temporary administrative task?

A. Giving every engineer permanent administrator access

B. Using a shared administrator password

C. Granting a narrowly scoped role that expires after the task

D. Allowing access based only on office network location

Correct Answer: C. Granting a narrowly scoped role that expires after the task

Question 3

What is the main security advantage of workload identity federation for a CI/CD system?

A. It removes the need for authorization policies

B. It avoids storing long-lived cloud credentials

C. It guarantees that application code is vulnerability-free

D. It makes all deployment environments public

Correct Answer: B. It avoids storing long-lived cloud credentials

Question 4

Which item is normally a secret?

A. A public documentation page

B. A database password

C. A non-sensitive application label

D. A published product version

Correct Answer: B. A database password

Question 5

In envelope encryption, what does a key-encryption key normally protect?

A. A data-encryption key

B. A firewall rule

C. A network route

D. A vulnerability report

Correct Answer: A. A data-encryption key

Question 6

Which control most directly limits lateral movement between cloud services?

A. Network segmentation with narrowly defined flows

B. Increasing the size of a virtual machine

C. Publishing more application documentation

D. Disabling all application logs

Correct Answer: A. Network segmentation with narrowly defined flows

Question 7

Which statement best describes zero trust?

A. All users inside a private network are trusted automatically

B. Access is explicitly evaluated using identity and relevant context

C. A VPN alone provides complete zero-trust security

D. Only physical security is required

Correct Answer: B. Access is explicitly evaluated using identity and relevant context

Question 8

Under the shared-responsibility model, which task is typically the customer’s responsibility?

A. Protecting the cloud provider’s physical buildings

B. Maintaining the provider’s global power systems

C. Configuring user permissions and MFA

D. Manufacturing the provider’s servers

Correct Answer: C. Configuring user permissions and MFA

Question 9

Which action is most appropriate when prioritizing vulnerabilities?

A. Fix every issue strictly by numeric severity score

B. Ignore vulnerabilities on internet-facing systems

C. Consider exploitability, exposure, asset value, and compensating controls

D. Patch only systems that have already failed

Correct Answer: C. Consider exploitability, exposure, asset value, and compensating controls

Question 10

Why are shared administrator accounts discouraged?

A. They make cloud storage impossible

B. They prevent encryption at rest

C. They weaken individual accountability and complicate revocation

D. They automatically improve network segmentation

Correct Answer: C. They weaken individual accountability and complicate revocation