Identity, Access Management, and Zero Trust

Introduction

Cloud computing changes the location, ownership, and scale of information systems, but it does not remove the need to determine who may access which resources and under what conditions. In a traditional data centre, access decisions were often based on network location: users inside a corporate network were treated as more trustworthy than users outside it. Cloud environments make this assumption unreliable. Users, workloads, devices, application programming interfaces (APIs), and administrators may connect from many networks and may access resources distributed across several providers.

Identity therefore becomes a primary security control. Identity and access management (IAM) establishes digital identities, verifies them, assigns permissions, and records their use. Zero trust extends this idea into an architectural principle: no request is trusted automatically merely because it originates from an internal network or a previously approved device. Each request should be evaluated using available evidence, appropriate policy, and the sensitivity of the requested action.

This chapter examines authentication, authorization, federation, single sign-on (SSO), multifactor authentication (MFA), role-based and attribute-based access control, privileged access management, least privilege, secrets management, conditional access, and zero-trust design. The objective is not simply to list technologies, but to explain how they combine into identity-centric controls suitable for cloud systems.

Learning Objectives

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

1. Distinguish identity, authentication, authorization, accounting, and access control.
2. Explain how federation, SSO, MFA, and modern authentication protocols operate.
3. Compare RBAC, ABAC, and policy-based authorization.
4. Design least-privilege permissions and privileged access controls.
5. Explain the secure storage, rotation, and use of secrets.
6. Apply conditional-access and zero-trust principles to cloud architectures.
7. Analyse IAM risks, governance obligations, and implementation trade-offs.

1. The Identity and Access Management Model

An identity is a representation of a subject that can participate in a digital system. A subject may be a person, service account, virtual machine, container, application, device, or automated process. An account is a system-specific record associated with an identity. A single human identity may have accounts in several cloud services, although federation can allow those accounts to be managed centrally.

IAM is commonly described through four related functions:

• Identification: The subject claims an identity, such as a username or account identifier.
• Authentication: The system verifies evidence supporting the claim.
• Authorization: The system determines what the authenticated subject may do.
• Accounting or auditing: The system records actions, decisions, and relevant context.

Authentication and authorization are different. A successfully authenticated employee may still be prohibited from reading a payroll database. Conversely, an application may be authorized to retrieve a limited set of records without being a human user.

A useful access-control abstraction is:

The subject is the requesting identity; the action is the operation, such as read or delete; the resource is the protected object; and the environment includes contextual facts such as device health, time, location, network, risk score, or authentication strength. The expression is a conceptual model rather than a universal implementation formula. Real platforms may use different policy languages and may evaluate additional inputs.

Identity lifecycle

Identity security begins before an account is created and continues after it is deleted. A typical lifecycle includes:

1. Proofing and registration: Establishing that an identity is genuine and belongs to the claimed person or system.
2. Provisioning: Creating accounts, assigning groups, issuing credentials, and associating devices or applications.
3. Use and review: Monitoring authentication and access, reviewing permissions, and responding to changes.
4. Modification: Updating access when a person changes role, department, location, or responsibility.
5. Suspension or deprovisioning: Removing or disabling access promptly when it is no longer justified.

Joiner–mover–leaver processes are particularly important. A joiner needs appropriate initial access; a mover needs old permissions removed as well as new permissions added; and a leaver must be disabled across relevant systems. Orphaned accounts and accumulated permissions are common causes of cloud compromise.

2. Authentication: Proving Identity

Authentication factors are commonly grouped into three categories:

MFA requires two or more independent factors. Entering a password and then answering a second password question is usually not strong MFA because both are knowledge factors. A password plus a phishing-resistant hardware security key provides stronger independence.

Passwords and passkeys

Passwords remain widespread, but they are vulnerable to phishing, reuse, guessing, credential stuffing, malware, and password database breaches. Security controls should support long, unique passwords, password managers, breached-password screening, rate limiting, and secure recovery. Systems should not rely solely on arbitrary complexity rules that encourage predictable patterns.

Passkeys use public-key cryptography. During registration, the authenticator creates a key pair. The private key remains protected by the device or authenticator, while the service stores the public key. During authentication, the service sends a challenge and the authenticator signs it. The service verifies the signature using the public key. A stolen database of public keys does not directly provide the private keys needed to authenticate. FIDO2 and WebAuthn are important standards in this area.

Authentication protocols

Cloud identity systems commonly use several protocols:

• SAML: An XML-based federation protocol often used for browser-based enterprise SSO.
• OAuth 2.0: An authorization framework that allows a client to obtain limited access to a resource server. OAuth by itself is not an authentication protocol.
• OpenID Connect (OIDC): An identity layer built on OAuth 2.0 that provides authentication claims through an identity token.
• Kerberos: A ticket-based protocol used in many enterprise directory environments.
• SCIM: A protocol for provisioning and managing identities and groups; it is not itself an authentication protocol.

A secure implementation must validate issuer, audience, signature, expiration, nonce or state values where applicable, redirect URIs, and token scope. Tokens should be short-lived where practical, and refresh tokens require strong protection and revocation processes.

Single sign-on and federation

SSO allows a user to authenticate once with an identity provider and then access multiple relying-party applications without separately entering credentials for each application. Federation extends trust across organizational or service boundaries. The identity provider authenticates the subject and issues an assertion or token that the relying party validates.

SSO improves usability and can reduce password reuse, but it also creates concentration risk. Compromise of a central identity provider may affect many applications. Consequently, the identity provider should receive especially strong protection: phishing-resistant MFA, administrative separation, robust logging, recovery planning, and carefully restricted federation trust.

3. Authorization Models

Authentication answers “Who are you?” Authorization answers “What may you do?” Authorization should be explicit, reviewable, and based on business or operational necessity.

Role-based access control

RBAC assigns permissions to roles and assigns subjects to roles. For example, a database analyst role may permit read access to a reporting database, whereas a database administrator role may permit schema changes. RBAC is understandable and manageable when organizational responsibilities are stable.

RBAC can become difficult when there are many exceptional cases. Excessive role creation produces role explosion, while broad roles violate least privilege. Role design should use meaningful job responsibilities, separate administrative and ordinary roles, and define ownership and review intervals.

Attribute-based access control

ABAC evaluates attributes of the subject, resource, action, and environment. An illustrative policy might permit a clinician to read a patient record only when the clinician is assigned to the patient, the purpose is treatment, the device is compliant, and the session has recent MFA. Attributes may include department, clearance, data classification, device status, geographic region, time, and transaction purpose.

ABAC supports fine-grained decisions but introduces complexity. Attribute quality, synchronization, policy testing, and explainability become important. Incorrect or stale attributes can produce either unauthorized access or unnecessary denial.

Policy-based and relationship-based authorization

Modern cloud systems often combine RBAC and ABAC in policy-based access control. A policy engine evaluates structured rules, while a policy administration point creates or manages policies and a policy enforcement point applies decisions. Relationship-based systems additionally evaluate relationships, such as whether a user is a member of a project that owns a document.

No access model is automatically superior. A practical design often uses RBAC for broad organizational structure and ABAC or relationship rules for sensitive, contextual decisions.

Deny by default and separation of duties

A secure authorization system denies access unless a valid policy grants it. Explicit deny rules are useful for protecting especially sensitive resources, but policy conflicts must be understood because platforms differ in how deny and allow statements are evaluated.

Separation of duties prevents one person or process from completing a risky chain of actions alone. For example, one employee may create a payment request while another approves it. In cloud operations, a developer may deploy code but not approve production access, or an administrator may request elevated privileges while a second party approves the request.

4. Least Privilege and Privileged Access Management

Least privilege means granting only the permissions required for an authorized task, for only as long as necessary, and in the appropriate context. It has three dimensions:

• Scope: Which resources and actions are allowed?
• Time: How long is access available?
• Context: Under which conditions may it be used?

Least privilege is not equivalent to denying everything. It is a process of matching permissions to verified tasks and reducing unnecessary authority.

Privileged access management (PAM) controls accounts and sessions with elevated capabilities. Good PAM practice includes separate administrative identities, just-in-time elevation, approval workflows, time limits, credential vaulting, session recording where lawful, command logging, emergency access procedures, and frequent review.

A common error is to protect human administrators while leaving powerful service principals permanently active. Non-human identities require the same discipline: narrowly scoped permissions, ownership, expiry, monitoring, and workload identity mechanisms where available.

Worked example: reducing an administrative role

Suppose a deployment service currently has permissions to read and delete all objects in a cloud storage account. Its documented task is to upload release packages to one container and read deployment manifests from another. A least-privilege redesign can:

1. Remove account-wide deletion permission.
2. Grant object creation only in the release container.
3. Grant read permission only in the manifest container.
4. Deny access to unrelated containers.
5. Bind the policy to the deployment workload identity rather than a shared password.
6. Require a separate approved process for deletion.

The redesigned policy is more complex than a broad administrator role, but it limits the impact of a compromised deployment process.

5. Secrets Management

A secret is sensitive information used to authenticate or authorize a system, including passwords, API keys, private keys, database credentials, certificates, signing keys, and tokens. Secrets should not be embedded in source code, container images, public configuration files, tickets, or unrestricted logs.

A secrets-management service should provide:

• Encryption in transit and at rest.
• Strict identity-based access to individual secrets.
• Versioning and controlled rotation.
• Audit records for retrieval and modification.
• Expiration and ownership metadata.
• Backup and recovery protection.
• Separation between secret administrators and application operators where appropriate.

Workloads should retrieve secrets at runtime through an authenticated identity, rather than receiving a permanent secret in a deployment script. Where possible, short-lived credentials and workload federation are preferable to static keys. Rotation must be tested: a secret that is rotated but cannot be updated in dependent applications may cause outages or encourage unsafe bypasses.

Certificates and private keys require special care. A certificate’s public portion may be distributed, but its private key must be protected. Key management systems, hardware security modules, and managed certificate services can reduce exposure, but they do not eliminate the need for correct authorization and lifecycle management.

6. Conditional Access and Risk-Adaptive Decisions

Conditional access evaluates contextual signals before allowing an action. Typical inputs include authentication strength, device compliance, application, network, location, time, user risk, sign-in risk, resource classification, and requested operation.

A conditional-access policy might require phishing-resistant MFA for administrative actions, block legacy authentication, restrict access to unmanaged devices, or permit low-risk document access while requiring stronger controls for downloading sensitive data. Policies should distinguish between user inconvenience and genuine risk reduction.

Risk signals are probabilistic and may be inaccurate. A location anomaly can arise from a mobile network or corporate proxy; a compliant device can still be compromised. Risk scoring should therefore support, not replace, strong baseline controls. Policies must include a secure break-glass process for identity-provider outages, with emergency accounts tightly protected and their use immediately reviewed.

7. Zero Trust Architecture

Zero trust is a security approach in which access is not granted solely because a subject is on a trusted network. It requires continuous evaluation of identity, device, workload, resource, and context. A useful conceptual sequence is:

1. Identify the subject and requested resource.
2. Authenticate the subject using appropriate assurance.
3. Evaluate device and workload posture.
4. Apply policy to action, resource, and context.
5. Grant the narrowest practical permission.
6. Monitor the session and reassess when risk changes.
7. Revoke or restrict access when conditions no longer justify it.

Zero trust does not mean that every request must use a new password or that network controls are irrelevant. Network segmentation, firewalls, and private connectivity remain useful, but they are defence-in-depth controls rather than proof of trust.

A zero-trust design commonly separates:

• Policy decision point: Determines whether access should be allowed.
• Policy enforcement point: Allows, blocks, or limits the request.
• Identity and device systems: Supply identity, authentication, and posture signals.
• Telemetry and analytics: Detect anomalous behaviour and support reassessment.

The principle of continuous verification must be applied carefully. Continuous does not necessarily mean re-authenticating every second. It means that access decisions can be revisited when significant events occur, such as a device becoming non-compliant, a session changing location, a token being revoked, or a user attempting a high-risk action.

Figure: A conceptual zero-trust access decision flow. The decision is based on identity and context rather than network location alone.

8. Governance, Ethics, and Compliance

IAM is both a technical and governance discipline. Organizations should define data owners, system owners, identity administrators, and reviewers. Access reviews should be evidence-based: reviewers need to know what permission exists, why it exists, when it was last used, and who approved it.

Logging should record successful and failed authentication, MFA changes, privilege elevation, policy changes, secret retrieval, token issuance, and administrative activity. Logs must be protected against alteration and should avoid exposing passwords, tokens, or unnecessary personal data.

Privacy is relevant because conditional access and behavioural analytics may process location, device identifiers, biometrics, and inferred risk. Organizations should apply purpose limitation, data minimization, retention controls, transparency, and appropriate legal safeguards. Biometric data deserves particular caution because a compromised fingerprint cannot be changed like a password.

Accessibility and inclusion also matter. MFA programs should provide secure alternatives for users with disabilities, users without reliable mobile connectivity, and users whose devices cannot support a chosen method. Security controls that exclude legitimate users often produce unsafe workarounds.

9. Implementation Roadmap and Best Practices

An organization introducing identity-centric cloud security can proceed in stages:

1. Inventory identities and resources: Include human, workload, machine, third-party, and emergency identities.
2. Centralize identity where appropriate: Establish a trusted identity provider and federation strategy.
3. Enforce strong authentication: Require MFA, prioritizing phishing-resistant methods for administrators.
4. Remove legacy authentication: Disable protocols that cannot enforce modern controls.
5. Design roles and policies: Use least privilege, separation of duties, and resource boundaries.
6. Protect privileged access: Introduce separate administrator accounts, just-in-time elevation, and approvals.
7. Implement secrets management: Replace embedded credentials with managed, short-lived access.
8. Deploy conditional access: Start with high-risk actions and sensitive resources, then refine using evidence.
9. Instrument and review: Monitor identity events, conduct access reviews, and test incident response.
10. Measure outcomes: Track MFA coverage, stale accounts, excessive privileges, time to revoke access, privileged-session coverage, and unresolved access-review findings.

Automation is valuable but must be governed. Automated deprovisioning can reduce delay, while automated policy generation can accidentally grant excessive access if source data or models are wrong. AI-assisted anomaly detection may identify unusual sign-ins or privilege use, but its decisions require validation, explainability, privacy safeguards, and a human response process.

10. Challenges and Limitations

IAM programs face several recurring difficulties. Hybrid and multicloud environments may use incompatible identity models and inconsistent policy semantics. Mergers and acquisitions create duplicate directories and uncertain ownership. Service accounts may lack clear custodians. Emergency access can bypass ordinary controls. Excessive alerts can cause analysts to ignore important signals.

Zero trust is not a product that can be purchased as a single package. It is an architectural and operational transformation. It cannot compensate for vulnerable applications, poor patching, insecure APIs, or unprotected data. Likewise, MFA reduces account takeover risk but does not prevent an authorized user from misusing access or an attacker from exploiting an already authenticated session.

Access decisions also involve trade-offs. Highly restrictive policies may protect data but disrupt legitimate work. Highly flexible policies may improve productivity but weaken assurance. Sound design therefore combines threat modelling, usability testing, staged deployment, measured exceptions, and continuous review.

Applied Case: Northbridge Health Services

Background

Northbridge Health Services is an illustrative multi-site healthcare organization using a cloud-based electronic health record, laboratory platform, collaboration service, and analytics environment. Clinicians, contractors, administrative staff, and automated services require different access levels.

Problem

An assessment finds shared administrator accounts, long-lived API keys, inconsistent MFA, broad group memberships, and delayed termination of contractor accounts. A stolen password is used to access the collaboration platform, and the attacker attempts to download patient-related documents.

Analysis

The organization’s main weaknesses are not simply weak passwords. They include poor identity lifecycle control, excessive privilege, insufficient separation of duties, and failure to evaluate device and resource context. Network location provides little protection because staff and contractors work remotely.

Approach

Northbridge establishes a central identity provider and federates supported applications. All users receive unique identities, while administrators use separate privileged accounts. Phishing-resistant MFA is required for administrators and high-risk operations. Contractors are connected to sponsor-owned groups with automatic expiry dates.

RBAC provides basic roles such as clinician, billing specialist, laboratory technician, and analyst. ABAC conditions access to sensitive records on patient assignment, treatment purpose, device compliance, and recent authentication. Just-in-time elevation is introduced for cloud administration. Workload identities replace static API keys, and remaining secrets are stored in a managed vault with rotation and audit logging.

Conditional access blocks legacy protocols, restricts sensitive downloads from unmanaged devices, and triggers stronger verification for anomalous sessions. Security staff monitor identity-provider logs and conduct monthly privileged-access reviews.

Outcome

The organization reduces standing administrative privileges, improves termination speed, and gains evidence showing why sensitive access occurred. The measures do not eliminate all risk, but they reduce the likelihood and potential impact of credential compromise while improving accountability.

Learning points

1. Central SSO is effective only when the central identity provider is strongly protected.
2. RBAC provides structure, but contextual decisions may require ABAC.
3. Workload identities and secrets management are as important as human MFA.
4. Zero trust requires policy, telemetry, enforcement, and governance together.
5. Security controls should be tested against operational and accessibility needs.

Chapter Summary

Identity is a central security boundary in cloud computing. Authentication verifies a claimed identity, while authorization evaluates whether that identity may perform a particular action on a particular resource. Federation and SSO improve manageability but increase the importance of protecting the identity provider. MFA, especially phishing-resistant methods, reduces credential-based attacks.

RBAC organizes permissions around responsibilities; ABAC evaluates subject, resource, action, and environmental attributes; and policy-based systems can combine both approaches. Least privilege limits scope, duration, and context. PAM protects elevated access through separate accounts, approval, just-in-time elevation, and monitoring. Secrets management replaces unsafe embedded credentials with controlled, auditable, and preferably short-lived credentials.

Conditional access uses contextual signals, while zero trust rejects implicit trust based on network location. Effective zero-trust architecture authenticates subjects, evaluates device and resource context, enforces narrow permissions, monitors activity, and reassesses decisions. IAM must also address privacy, accessibility, governance, compliance, lifecycle management, and operational resilience.

Key Terms

Identity: A representation of a subject in a digital system.

Authentication: Verification of a claimed identity.

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

Accounting: Recording identity, access, and administrative events.

MFA: Authentication using two or more independent factors.

SSO: Access to multiple applications after one authentication event.

Federation: Trust relationship allowing identity assertions to be accepted across systems or organizations.

SAML: A protocol commonly used for browser-based identity federation.

OAuth 2.0: An authorization framework for delegated, limited access.

OpenID Connect: An authentication layer built on OAuth 2.0.

RBAC: Access control based on organizational roles.

ABAC: Access control based on attributes and policy conditions.

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

PAM: Controls for managing privileged accounts and sessions.

Secrets management: Secure storage, use, rotation, and auditing of credentials and keys.

Conditional access: Policy decisions based on identity and contextual signals.

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

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

Separation of duties: Dividing sensitive responsibilities among different subjects.

Policy enforcement point: A component that permits, blocks, or limits a request according to policy.

Review Questions

5 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 risk of SSO.
4. What is meant by least privilege?
5. Name three types of information that conditional access may evaluate.

5 Long Answer Questions

1. Explain the identity lifecycle and describe how joiner–mover–leaver processes reduce cloud risk.
2. Compare RBAC and ABAC, including an example in which combining them would be useful.
3. Describe the main components of a privileged access management program.
4. Explain how secrets should be stored, accessed, rotated, and audited in a cloud environment.
5. Discuss why zero trust is an architectural approach rather than a single security product.

3 Analytical / Application Questions

1. A software deployment account can administer every resource in a cloud subscription, although it only deploys code to one application. Design a least-privilege replacement and identify controls for monitoring and emergency recovery.
2. A remote employee signs in successfully from a compliant device, but attempts to download highly sensitive records from an unusual location. Design a conditional-access response and explain the trade-offs.
3. Analyse the Northbridge Health Services case. Identify two human-identity controls, two workload-identity controls, and two governance controls that should be prioritized, and justify your choices.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication grants permissions, while authorization verifies identity.

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

C. Authentication records events, while authorization encrypts data.

D. Authentication applies only to applications, while authorization applies only to people.

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

Question 2

Which combination provides two independent authentication factors?

A. Password and security-question answer

B. Password and another password

C. Password and hardware security key

D. Username and email address

Correct Answer: C. Password and hardware security key

Question 3

What is the primary purpose of OpenID Connect?

A. To provide an identity layer on OAuth 2.0

B. To replace all network firewalls

C. To provision user accounts through SCIM

D. To encrypt database backups

Correct Answer: A. To provide an identity layer on OAuth 2.0

Question 4

Which access-control model evaluates subject, resource, action, and environmental attributes?

A. RBAC

B. ABAC

C. DAC only

D. Password-based access control

Correct Answer: B. ABAC

Question 5

Which practice most directly implements least privilege for a temporary administrative task?

A. Giving every administrator permanent global access

B. Using a shared administrator password

C. Granting time-limited, approved elevation for the required resource

D. Disabling all audit logging during the task

Correct Answer: C. Granting time-limited, approved elevation for the required resource

Question 6

Why should secrets generally not be embedded in source code?

A. Source code cannot contain text characters

B. Repositories and copies may expose credentials to unauthorized parties

C. Embedded secrets always improve rotation

D. Cloud services cannot use credentials stored in files

Correct Answer: B. Repositories and copies may expose credentials to unauthorized parties

Question 7

Which statement reflects a zero-trust principle?

A. Internal network location is sufficient proof of trust.

B. Users should be trusted permanently after their first login.

C. Access should be evaluated using identity, context, and resource sensitivity.

D. Zero trust eliminates the need for authentication.

Correct Answer: C. Access should be evaluated using identity, context, and resource sensitivity.

Question 8

What is a major risk of centralized SSO?

A. It necessarily creates more passwords for users.

B. Compromise of the identity provider can affect many connected applications.

C. It prevents centralized access reviews.

D. It cannot use MFA.

Correct Answer: B. Compromise of the identity provider can affect many connected applications.

Question 9

Which is an example of separation of duties?

A. One shared account performs every financial operation.

B. A developer both requests and independently approves production access.

C. One employee prepares a payment and another approves it.

D. All users receive identical permissions.

Correct Answer: C. One employee prepares a payment and another approves it.

Question 10

Which control is most appropriate for a workload that needs access to one storage container without a permanent API key?

A. A workload identity with narrowly scoped permissions

B. A global administrator account stored in the application

C. A password committed to the deployment repository

D. An anonymous public bucket policy

Correct Answer: A. A workload identity with narrowly scoped permissions