Identity, Security and Zero-Trust Architecture

Introduction

Cloud architecture has changed the location, scale and speed of computing, but it has not removed the fundamental security problem: a system must ensure that only the right subject can perform the right action on the right resource under the right conditions. In cloud environments, this problem is complicated by elastic infrastructure, software-defined networks, managed services, remote administration, APIs, distributed data and multiple identity providers.

Traditional perimeter security assumed that users and systems inside a corporate network could be trusted more than those outside it. Cloud computing makes that assumption unreliable. A user may be working from a corporate office, a home network or a mobile device; a workload may move between hosts; and a request may cross several providers. Modern security therefore treats identity, device condition, workload identity, data sensitivity and request context as central security controls.

This chapter examines identity and access management (IAM), federation, least privilege, role-based and attribute-based access control, secrets and key management, encryption, certificates, zero-trust architecture, secure APIs, threat modelling, vulnerability management and cloud security posture management (CSPM). The emphasis is practical: students should be able to analyse a cloud design, identify trust assumptions, select appropriate controls and explain the trade-offs involved.

Learning Objectives

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

1. Explain the components and lifecycle of cloud identities.
2. Distinguish authentication, authorization, accounting and federation.
3. Apply least privilege using RBAC, ABAC and policy-based controls.
4. Design suitable approaches to secrets, keys, encryption and certificates.
5. Explain zero-trust principles and apply them to cloud architectures.
6. Assess API security risks and recommend protective controls.
7. Conduct a practical threat-modelling exercise.
8. Relate vulnerability management and CSPM to continuous assurance.
9. Evaluate governance, privacy, ethical and operational implications of cloud security decisions.

1. The Identity-Centred Cloud Security Model

Security is often described using the CIA triad:

• Confidentiality: preventing unauthorized disclosure.
• Integrity: preventing unauthorized or undetected alteration.
• Availability: ensuring that authorized users can access systems and data when required.

Identity controls support all three objectives. Strong authentication protects confidentiality, authorization protects integrity, and resilient identity services support availability. However, identity is not limited to human users. A cloud identity may represent a person, service account, virtual machine, container, serverless function, device, pipeline or external organization.

A useful access decision can be expressed conceptually as:

Here, Subject is the requesting identity, Action is the operation, Resource is the protected object, and Environment includes context such as device health, network location, time, data classification and risk signals. The expression is a policy model rather than a numerical equation; it emphasizes that authorization should evaluate context rather than merely network location.

Authentication and authorization

Authentication answers, “Who or what is making this request?” Authorization answers, “What is that subject allowed to do?” Accounting or auditing records what happened. These functions must be separated. A successfully authenticated user is not automatically authorized to read every database, and an authorization decision is not useful if it cannot be audited.

Authentication factors are commonly classified as:

• Knowledge: password or personal identification number.
• Possession: hardware token or authenticator application.
• Inherence: biometric characteristic.
• Location and behaviour: contextual signals, normally used as additional risk evidence rather than as a sole factor.

Multi-factor authentication (MFA) combines independent factors. A password and a second password are not genuine MFA because both are knowledge factors. Phishing-resistant methods, such as hardware-backed passkeys using public-key cryptography, are generally stronger than passwords and one-time codes against credential theft.

2. IAM Architecture and Federation

A mature IAM architecture normally contains the following components:

Federation allows one organization or system to trust identity assertions issued by another. In workforce access, Security Assertion Markup Language (SAML) is common for browser-based enterprise single sign-on, while OpenID Connect (OIDC) provides an identity layer over OAuth 2.0 and is widely used by modern applications. OAuth 2.0 is primarily an authorization framework; it should not be described as an authentication protocol by itself.

A federated flow typically involves:

1. A user authenticates with the trusted IdP.
2. The IdP issues an assertion or token for a particular audience.
3. The application validates issuer, signature, audience, expiry and relevant claims.
4. The application maps claims to local permissions.
5. Events are recorded for investigation and compliance.

Trust must be explicit and bounded. Important checks include issuer identity, token signature, signing-key rotation, audience restriction, nonce or state protection where applicable, short token lifetimes and safe handling of clock differences. Federation reduces password duplication but creates dependence on the IdP; an outage or compromise can affect many services.

Identity lifecycle

Identity governance follows a lifecycle:

• Joiner: create the account and assign only approved initial access.
• Mover: modify access when the person changes role or department.
• Leaver: disable sessions, credentials, tokens and accounts promptly.
• Review: periodically recertify privileges, especially for privileged roles.

Automation should be connected to authoritative sources such as human-resources systems, asset inventories and service deployment pipelines. Orphaned accounts, shared accounts and long-lived access keys are common indicators of weak lifecycle management.

3. Least Privilege, RBAC and ABAC

Least privilege means granting only the permissions necessary for an approved task, for the shortest practical duration, through the most appropriate identity. It is not the same as denying everything permanently. Excessively restrictive policies can cause unsafe workarounds, so least privilege must be tested against operational requirements.

Role-based access control

RBAC assigns permissions to roles and roles to subjects. Examples include BillingViewer, ApplicationOperator and DatabaseAdministrator. RBAC is easy to explain and govern when job functions are stable. Its limitation is role explosion: many combinations of department, environment and resource can produce an unmanageable number of roles.

Attribute-based access control

ABAC evaluates attributes of the subject, resource, action and environment. An illustrative policy might allow a user to read records when:

• the user’s department equals the data owner’s department;
• the user has completed required training;
• the resource classification is no higher than the user’s clearance; and
• the request originates from a compliant device.

ABAC provides fine-grained, context-sensitive decisions but depends on accurate, protected attributes. A false or stale attribute can produce an incorrect access decision. Attribute sources, update frequency and conflict resolution must therefore be governed.

Policy design practices

Policies should be explicit about effect, principal, action, resource and conditions. Prefer resource-specific permissions over broad wildcards. Separate read, write, delete, administration and policy-management privileges. Use deny conditions for high-risk situations, but test policy precedence carefully because different platforms implement explicit deny, inheritance and conflict resolution differently.

Privileged access should be time-bound and approved where possible. Just-in-time elevation, privileged access workstations, session recording, break-glass accounts and independent review are useful controls. Break-glass accounts must be protected for emergencies but monitored because they bypass normal workflows.

4. Secrets, Keys, Encryption and Certificates

Secrets management

Secrets include passwords, API tokens, database connection strings, private keys and signing credentials. They should not be embedded in source code, container images, tickets or unencrypted configuration files. A secrets manager should provide protected storage, controlled retrieval, audit logging, rotation and integration with workload identities.

Applications should retrieve secrets at runtime using a narrowly scoped identity. Secret values should not be written to logs, error messages or crash dumps. Rotation must be operationally tested: a secret that can be rotated only by manually changing dozens of applications is not effectively managed.

Cryptographic keys

A key-management service (KMS) or hardware security module (HSM) can generate, store, use and rotate keys while restricting direct export. Key-management design must distinguish:

• Data-encryption keys (DEKs), used to encrypt data;
• Key-encryption keys (KEKs), used to encrypt or wrap DEKs; and
• Signing keys, used to provide authenticity and integrity rather than confidentiality.

Envelope encryption commonly works as follows: a service requests a DEK, encrypts data with the DEK, and stores the encrypted DEK protected by a KEK. Key destruction, backup, regional availability, separation of duties and recovery procedures must be addressed before deployment.

Encryption in transit and at rest

Encryption in transit protects communication against interception and tampering. TLS should be configured with current protocol versions, suitable cipher suites, authenticated certificates and proper hostname validation. Encryption at rest protects storage media and backups, but it does not protect data after an authorized application has decrypted it. Sensitive applications may require field-level or application-level encryption, tokenization or confidential-computing techniques.

Encryption does not replace access control. A database encrypted with a key accessible to every administrator may provide limited protection against privileged misuse. Conversely, a perfectly designed key system cannot compensate for an application that authorizes the wrong user.

Certificate management

Certificates bind a public key to an identity through a certificate authority (CA). Operational controls include inventory, automated issuance, renewal before expiry, revocation strategy, private-key protection, correct hostname validation and monitoring of trust-store changes. Short-lived certificates reduce exposure but increase the need for reliable automation. Certificate failures can cause outages, so renewal should be tested in staging and monitored as an operational dependency.

5. Zero-Trust Architecture

Zero trust is a security approach in which no request is trusted merely because it originates from a particular network location. The core ideas are verify explicitly, use least privilege and assume breach. Zero trust is not a single product and does not mean that every request must be manually approved. It means that access decisions are continuously based on authenticated identity, resource policy and relevant context.

A zero-trust architecture commonly includes:

• strong human and workload identity;
• device and workload posture assessment;
• policy decision and enforcement points;
• microsegmentation and service-to-service authorization;
• continuous logging and analytics;
• data classification and protection;
• automated response and recovery.

Figure: A zero-trust access decision combines identity, device and resource context before enforcement.

Zero trust must be implemented incrementally. An organization can begin with inventory, MFA and privileged-account controls, then introduce workload identity, segmentation, service authorization and continuous policy evaluation. A common failure is to purchase a zero-trust product without defining protected resources, decision criteria, ownership and measurable outcomes.

6. Secure APIs and Cloud-Native Workloads

APIs are the principal control plane of cloud services and therefore attractive targets. Important API risks include broken object-level authorization, excessive data exposure, injection, replay, credential theft, insecure defaults, weak rate controls and insufficient logging.

Secure API design should include:

1. Authentication using validated tokens, mutual TLS or workload identity where appropriate.
2. Authorization at every object boundary, not merely at the route level.
3. Input validation using allow-lists, type checks, length limits and schema validation.
4. Output minimization so that responses contain only necessary fields.
5. Rate limiting and quotas to reduce abuse and protect availability.
6. Replay protection, idempotency controls and suitable token lifetimes.
7. Transport security with certificate validation and secure protocol configuration.
8. Centralized, privacy-aware logging of decisions and significant failures.
9. Version and dependency management so obsolete endpoints are retired.

In microservices, each service should authenticate the calling workload and authorize the requested operation. Network reachability is not authorization. Service meshes can assist with mutual TLS, traffic policy and telemetry, but they do not automatically correct application-level authorization errors.

7. Threat Modelling and Security Analysis

Threat modelling is a structured method for identifying what can go wrong and selecting proportionate controls. A practical process is:

1. Define system scope, assets and security objectives.
2. Draw data-flow diagrams showing trust boundaries and external dependencies.
3. Identify actors, entry points and privileged operations.
4. Enumerate threats using a framework such as STRIDE.
5. Estimate likelihood and impact.
6. Select preventive, detective and corrective controls.
7. Assign owners and revisit the model after architectural change.

STRIDE classifies threats as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. It is a useful brainstorming taxonomy rather than a complete risk calculation.

A simple risk-ranking model is:

The factors may be scored on an agreed ordinal scale, such as 1 to 5. This produces a prioritization aid, not a probability or monetary loss unless the scales have been formally defined. Teams should document assumptions and avoid presenting ordinal scores as precise measurements.

For example, a public administrative API might be assessed as likelihood 4 and impact 5, giving a risk score of 20 on the chosen scale. The result supports prioritization of phishing-resistant MFA, strong authorization, network restrictions, logging and independent testing. It does not prove that the event has a 20 percent probability.

8. Vulnerability Management and CSPM

Vulnerability management is a lifecycle rather than a one-time scan:

• discover assets and software;
• identify vulnerabilities and misconfigurations;
• validate findings and assess exposure;
• prioritize according to exploitability, business impact and compensating controls;
• remediate, mitigate or formally accept risk;
• verify closure and report trends.

Scanning must cover infrastructure, images, dependencies, source code, identities, APIs and managed-service configurations. A vulnerability scanner can produce false positives and false negatives; critical findings require human validation and contextual analysis.

CSPM tools compare cloud configurations with policies, benchmarks and organizational rules. Typical findings include public storage, unrestricted management ports, disabled logging, overly permissive IAM, unencrypted resources and missing backups. CSPM is valuable for continuous visibility, but automated remediation can be dangerous if it changes production resources without dependency analysis, approval or rollback.

Security posture should be measured with meaningful indicators such as percentage of assets inventoried, age of critical findings, MFA coverage, privileged-access review completion, public-resource exposure and mean time to remediate. Metrics should distinguish activity from outcome: the number of scans is less informative than the reduction in exploitable exposure.

9. Governance, Ethics and Compliance

Cloud security decisions involve legal and ethical responsibilities. Organizations should apply data minimization, purpose limitation, retention controls and appropriate access to personal data. Encryption keys and logs may themselves contain sensitive information. Cross-border replication can create jurisdictional obligations, while central monitoring can become excessive employee surveillance if not governed transparently.

Important governance practices include separation of duties, documented risk acceptance, change approval, incident response exercises, evidence retention and independent audit. Compliance frameworks can guide control selection, but compliance is not equivalent to security. A control may satisfy a checklist while failing to address a particular threat or business process.

Security professionals must also consider accessibility, fairness and proportionality. Automated risk scoring can incorrectly classify legitimate users, and AI-assisted security tools may amplify biased or incomplete training data. Human review, explainability for consequential decisions and protected audit trails are necessary when automation affects access to critical services.

10. Illustrative Case: Federated Access for a Healthcare Platform

Background

A regional healthcare provider moves its appointment, laboratory and billing services to a multi-cloud platform. Staff authenticate through an existing enterprise identity provider, while applications use APIs and managed databases. The organization must protect health information, support remote clinicians and maintain availability during an identity-provider outage.

Problem

An initial design uses long-lived service-account keys, broad administrator roles and a single shared database credential. Several APIs trust network location and do not verify whether a clinician may access a particular patient record. Logging is inconsistent, and certificates are renewed manually.

Analysis

The main threats are credential theft, excessive privilege, broken object-level authorization, insider misuse, secret leakage, certificate expiry and IdP dependency. The data is highly sensitive, so confidentiality and auditability are particularly important. Availability also matters because clinicians require timely access during care delivery.

Approach and solution

The provider adopts federated SSO with phishing-resistant MFA for staff and separate workload identities for services. Human access is assigned through a combination of job roles and attributes such as department, care relationship and emergency status. Patient-record authorization is enforced in the application, not inferred from network location.

Long-lived keys are replaced with short-lived tokens and managed workload identity. Database credentials are stored in a secrets manager and rotated automatically. Data is encrypted in transit and at rest, with key access separated from database administration. Certificates are issued and renewed automatically, with expiry monitoring.

API gateways enforce schema validation, quotas and token validation, while services perform object-level authorization. Centralized logs record identity, resource, action, decision and correlation identifier without unnecessarily recording medical content. A break-glass procedure permits emergency access, but requires a reason, enhanced logging and retrospective review.

CSPM continuously checks public exposure, encryption, logging and IAM configuration. Threat models are updated for every major service change. A limited emergency operating mode provides approved read-only access to cached non-sensitive operational information if the primary IdP is unavailable; it does not create an uncontrolled bypass.

Outcome

The revised architecture reduces standing privilege, improves traceability and makes unauthorized cross-patient access less likely. It also introduces operational costs: identity integration, policy testing, certificate automation and incident-response training require sustained investment. The provider therefore treats security as an operating capability rather than a one-time migration task.

Learning points

1. Federation reduces duplicate credentials but creates a critical dependency.
2. Network location cannot substitute for resource-level authorization.
3. Workload identities and short-lived credentials are preferable to shared keys.
4. Emergency access must be controlled and auditable.
5. Security controls must be designed with availability and clinical workflows in mind.

11. Best Practices and Limitations

A practical baseline for cloud identity and security includes:

• require MFA, prioritizing phishing-resistant methods for privileged users;
• eliminate shared accounts and inventory all human and workload identities;
• use short-lived credentials and automate rotation;
• implement least privilege with tested policies and periodic recertification;
• separate production, development and security-administration duties;
• protect keys in managed services or HSMs where appropriate;
• automate certificate issuance and renewal;
• enforce authorization at every API and object boundary;
• centralize tamper-resistant audit logs and monitor high-risk events;
• continuously scan configurations, images, code and dependencies;
• test incident response, recovery and break-glass procedures;
• measure exposure and remediation outcomes rather than tool activity alone.

These controls have limitations. Strong authentication does not stop an authorized insider from misusing access. Encryption cannot protect data after legitimate decryption. Zero trust can increase design and operational complexity. Automated policy enforcement may cause outages if policies are inaccurate. Security teams must therefore balance confidentiality, integrity, availability, usability, cost and resilience through documented risk decisions.

Contemporary Developments

Cloud security is increasingly influenced by confidential computing, workload identity federation, passkeys, software supply-chain security, policy-as-code and security analytics. Confidential-computing technologies attempt to protect data during processing using hardware-enforced trusted execution environments, although they introduce attestation, vendor-dependence and performance considerations. Policy-as-code enables version-controlled, tested security rules in deployment pipelines. AI can assist with anomaly detection, alert triage and policy analysis, but it should not be trusted blindly: generated recommendations require validation, and sensitive logs must not be exposed to unauthorized models or providers.

The direction of travel is clear: security decisions are becoming more continuous, contextual and automated. Professional practice still depends on sound identity governance, explicit policy, reliable inventory, human accountability and disciplined engineering.

Chapter Summary

Cloud security begins with trustworthy identity and explicit authorization. IAM encompasses human and workload identities, authentication, authorization, federation, lifecycle governance and audit. Least privilege can be implemented through RBAC, ABAC, short-lived access and just-in-time elevation, but policies must be tested and attributes governed.

Secrets, cryptographic keys and certificates require separate lifecycle controls. Encryption protects data in transit and at rest but does not replace authorization. Zero trust rejects implicit trust based on network location and evaluates identity, device, workload, resource and environmental context for each request.

Secure APIs require strong authentication, object-level authorization, input validation, rate controls, safe token handling and comprehensive logging. Threat modelling identifies assets, boundaries and attack paths, while vulnerability management and CSPM provide continuous assurance. Governance must address privacy, regulation, ethics, availability and accountability. The most effective architecture combines technical controls with operational processes, measurable outcomes and regular reassessment.

Key Terms

ABAC: Access control based on subject, resource, action and environmental attributes.

Authentication: Verification of the identity of a subject.

Authorization: Determination of what an authenticated subject may do.

Certificate authority: Trusted entity that issues and signs digital certificates.

CSPM: Cloud security posture management; continuous assessment of cloud configurations and controls.

Data-encryption key: Key used directly to encrypt data, commonly protected by a key-encryption key.

Federation: Trust relationship in which one identity provider supplies identity assertions to another service.

IAM: Identity and access management.

Identity provider: Service that authenticates subjects and issues identity assertions or tokens.

Just-in-time access: Temporary privilege granted only when required.

Least privilege: Granting only necessary permissions for an appropriate duration.

MFA: Authentication using two or more independent factors.

Mutual TLS: TLS configuration in which both communicating parties authenticate with certificates.

OIDC: OpenID Connect, an identity protocol built on OAuth 2.0.

RBAC: Access control based on roles and associated permissions.

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

Threat modelling: Structured identification and treatment of potential security threats.

Zero trust: Security approach that removes implicit trust and verifies requests using identity and context.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. Why is OAuth 2.0 not, by itself, an authentication protocol?
3. State two advantages and one limitation of RBAC.
4. What is envelope encryption?
5. List the three central principles commonly associated with zero trust.

Long Answer Questions

1. Explain the identity lifecycle from joiner to leaver and discuss how automation can reduce risk.
2. Compare RBAC and ABAC for a multi-department cloud application.
3. Describe a secure design for secrets, encryption keys and certificates in a cloud-native system.
4. Explain how threat modelling, vulnerability management and CSPM complement one another.
5. Discuss the governance, privacy and availability challenges of federated cloud identity.

Analytical / Application Questions

1. A service uses a shared database password stored in a container image and allows any authenticated employee to read customer records. Analyse the weaknesses and propose a prioritized remediation plan.
2. Design a zero-trust access decision for a privileged administrator connecting from an unmanaged device to a production API. Identify the signals, policy outcome and audit evidence required.
3. A CSPM tool reports that a storage bucket is public, but the application team claims that the data is non-sensitive. Explain how you would validate the finding, assess risk and decide whether remediation or formal risk acceptance is appropriate.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines permissions, while authorization verifies identity.

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

C. Authentication encrypts data, while authorization stores audit logs.

D. Authentication creates certificates, while authorization rotates keys.

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

Question 2

Which protocol provides an identity layer over OAuth 2.0?

A. SAML

B. TLS

C. OIDC

D. SSH

Correct Answer: C. OIDC

Question 3

Which practice most directly implements least privilege for emergency administrator access?

A. Giving all administrators permanent owner permissions

B. Using a shared administrator password

C. Granting time-bound, approved elevation with auditing

D. Allowing access whenever the request comes from the corporate network

Correct Answer: C. Granting time-bound, approved elevation with auditing

Question 4

What is the primary purpose of a data-encryption key in envelope encryption?

A. To authenticate a user to an identity provider

B. To encrypt data, while its protected copy is managed by a higher-level key

C. To issue a digital certificate

D. To define an RBAC role

Correct Answer: B. To encrypt data, while its protected copy is managed by a higher-level key

Question 5

Which statement is consistent with zero-trust architecture?

A. Internal network traffic is trusted automatically.

B. A VPN eliminates the need for authorization.

C. Every request is evaluated using identity and relevant context.

D. Only external users require authentication.

Correct Answer: C. Every request is evaluated using identity and relevant context.

Question 6

Which control addresses broken object-level authorization in an API?

A. Checking only whether the request uses HTTPS

B. Verifying that the caller may access the specific requested object

C. Increasing the API response size limit

D. Disabling audit logging

Correct Answer: B. Verifying that the caller may access the specific requested object

Question 7

In STRIDE, which category concerns unauthorized modification of data?

A. Tampering

B. Spoofing

C. Repudiation

D. Information disclosure

Correct Answer: A. Tampering

Question 8

What is a major risk of long-lived service-account keys?

A. They cannot be used by automated systems.

B. They increase exposure if copied or leaked before rotation.

C. They prevent encryption at rest.

D. They automatically enforce object-level authorization.

Correct Answer: B. They increase exposure if copied or leaked before rotation.

Question 9

What is a primary function of CSPM?

A. Writing application business logic

B. Assessing cloud configurations against security policies and benchmarks

C. Replacing all identity providers

D. Decrypting every application database

Correct Answer: B. Assessing cloud configurations against security policies and benchmarks

Question 10

Why should a certificate-management process include expiry monitoring?

A. Expired certificates can cause service outages and failed authentication.

B. Monitoring prevents all phishing attacks.

C. Expiry monitoring eliminates the need for private-key protection.

D. Certificates are used only for data-at-rest encryption.

Correct Answer: A. Expired certificates can cause service outages and failed authentication.