3. Cloud Identity, Access and Privileged Security

Introduction and Context

Cloud computing changes the security boundary of an organisation. In a traditional data centre, access decisions were often associated with a corporate network, a fixed directory, and identifiable server locations. In a cloud environment, users may work from unmanaged devices, applications may span several providers, and workloads may create resources dynamically through application programming interfaces (APIs). The central security question is therefore no longer simply whether a request originates inside the network. It is whether a correctly identified subject is permitted to perform a specific action on a particular resource under defined conditions.

Identity has consequently become a primary control plane for cloud security. A compromised identity can provide an attacker with access to data, administrative interfaces, virtual machines, storage, encryption keys, and deployment pipelines without requiring a conventional network intrusion. Conversely, a well-designed identity architecture can limit the effect of stolen credentials, separate administrative duties, and create reliable evidence for investigation.

This chapter examines cloud identity and access management (IAM) as an integrated discipline. It covers federation and single sign-on (SSO), multifactor authentication (MFA), role-based and attribute-based access control, workload identities, secrets management, privileged access management (PAM), and identity governance. Particular attention is given to credential attacks, permission creep, excessive entitlements, and toxic combinations of access that allow one person or identity to defeat important controls.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain the role of identity as a cloud security control plane.

2. Distinguish authentication, authorisation, accountability, federation, SSO, MFA, RBAC, ABAC, and entitlement management.

3. Design a federation and SSO approach appropriate for a multi-cloud organisation.

4. Apply least privilege to human users, workloads, service accounts, and administrators.

5. Explain how secrets should be stored, issued, rotated, monitored, and revoked.

6. Analyse credential attacks, permission creep, toxic combinations, and privilege escalation paths.

7. Propose a governance and PAM programme that balances security, usability, resilience, and operational need.

Identity as the Cloud Security Control Plane

An identity is a representation of a human, application, service, device, or automated process. A subject uses an identity to request an operation on a resource. The resource may be a database, object-storage bucket, virtual machine, container cluster, API, encryption key, or administrative function. Access control evaluates the request and produces a decision: permit, deny, or sometimes require additional controls such as step-up authentication or approval.

Four related activities should be distinguished. Identification is the claim of who or what the subject is. Authentication verifies that claim. Authorisation determines what the authenticated subject may do. Accounting, often called auditing or accountability, records relevant actions so that they can be reviewed and attributed. Confusing authentication with authorisation is a common design error: proving that a user is Alice does not establish that Alice may delete production data.

Cloud IAM typically includes a central identity provider (IdP), one or more cloud-provider directories, policy engines, entitlement repositories, authentication mechanisms, logging systems, and governance workflows. The architecture must address both interactive identities and non-human identities. A developer signing into a console, a pipeline deploying infrastructure, a container retrieving a database password, and a security analyst reviewing logs are all identity-mediated activities, although they should not use identical credentials or permissions.

The principle of least privilege requires an identity to receive only the access necessary for an approved purpose, for the shortest practical period, and within the appropriate scope. Least privilege is not equivalent to granting a broad administrator role temporarily whenever convenient. It requires understanding tasks, resources, conditions, duration, and accountability. Other important principles include separation of duties, deny-by-default, explicit ownership, continuous verification, and resistance to single points of administrative failure.

Federation, SSO and Strong Authentication

Identity federation allows one organisation or identity domain to trust authentication performed by another domain. Instead of creating independent passwords in every cloud service, an enterprise can authenticate users through its corporate IdP and communicate identity assertions to service providers. Common federation technologies include Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and OAuth 2.0. SAML is widely used for browser-based enterprise SSO, while OIDC provides an identity layer over OAuth 2.0 and is common in modern applications. OAuth 2.0 itself is primarily an authorisation framework, not an authentication protocol.

SSO improves usability and can reduce password reuse, because users authenticate to a trusted IdP rather than maintaining separate credentials for every service. It also centralises lifecycle actions. When an employee leaves, disabling the corporate identity can remove access from many connected services. However, SSO concentrates risk. Compromise of the IdP, federation keys, administrator accounts, or token-issuance processes can affect a large portion of the enterprise. Federation therefore requires resilient IdP design, protected signing keys, careful trust configuration, monitoring, and emergency access procedures.

A useful federation design defines the source of authority for identity attributes, the accepted authentication assurance level, token lifetime, audience restrictions, group-to-role mappings, clock and certificate management, and the procedure for revoking access. Role assignment should not be based solely on an ungoverned user-supplied attribute. Groups should have owners, membership rules, review schedules, and documented business purposes.

MFA requires two or more independent authentication factors. These factors are commonly categorised as something the user knows, has, or is. Passwords and personal identification numbers are knowledge factors; hardware security keys and authenticator applications provide possession factors; biometric characteristics are inherence factors. MFA substantially reduces the value of a stolen password, but not all MFA is equally resistant to attack. Push-fatigue attacks, SIM swapping, malware, adversary-in-the-middle phishing, and social engineering can defeat weaker implementations.

Phishing-resistant methods, particularly cryptographic security keys and passkeys based on public-key authentication, provide stronger protection because the authenticator verifies the legitimate relying party and does not disclose a reusable secret. Administrative, remote, high-risk, and recovery operations should normally require the strongest available authentication. Recovery processes deserve equal attention: an attacker may bypass strong MFA by persuading a help desk to reset the factor.

Authorisation Models for Cloud Environments

Role-Based Access Control

Role-based access control (RBAC) assigns permissions to roles and assigns subjects to roles. A role such as “read-only security analyst” may allow log access and investigation without permitting configuration changes. RBAC simplifies administration when job functions are stable and understandable. It also supports separation of duties by assigning incompatible functions to different roles.

RBAC becomes difficult when roles are created by accumulating permissions for individual requests. Such roles become broad, poorly named, and rarely reviewed. A sound role engineering process begins with business tasks, identifies required actions and resources, separates read, write, administrative, and destructive functions, and defines ownership and review criteria. Cloud-native roles should be scoped by account, project, subscription, resource group, service, and action wherever possible.

Attribute-Based Access Control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might allow a finance analyst to read records tagged “financial-reporting” during an approved work period from a managed device, but deny export operations. Attributes can include department, employment status, data classification, resource owner, network context, device posture, time, and authentication strength.

ABAC is expressive and useful in dynamic cloud environments, but it introduces policy complexity. Attribute quality, freshness, naming consistency, and governance become critical. An incorrectly populated department attribute can produce unintended access at scale. Policies should therefore be testable, explainable, version-controlled, and evaluated using representative identities and resources.

Most mature environments use a hybrid approach. RBAC expresses relatively stable job functions, while ABAC adds contextual restrictions and resource conditions. Neither model eliminates the need for access reviews or careful policy analysis.

Entitlements and Effective Permissions

An entitlement is a permission, role membership, group membership, policy attachment, or other grant that enables access. Effective permissions are the permissions a subject actually possesses after direct grants, inherited roles, nested groups, resource policies, session policies, and organisation-wide controls are combined. Effective access can therefore be much greater than a manager or user expects.

Entitlement management addresses the complete lifecycle of access: request, approval, provisioning, use, review, modification, and removal. It should identify who owns an entitlement, why it exists, what evidence supports it, when it expires, and what other entitlements interact with it. Access certification should be risk-based rather than a meaningless exercise in approving long lists of names.

Workload Identities and Non-Human Access

Cloud workloads require identities to call APIs, retrieve data, publish messages, and access other services. Historically, developers embedded long-lived access keys in source code or configuration files. This practice creates substantial risk because keys may enter source repositories, build logs, container images, backups, or support tickets.

A workload identity associates a service, pod, virtual machine, function, or deployment pipeline with a short-lived identity. The workload receives a token or credential only when it is running in an approved context, and the authorisation policy limits its actions and resources. Federation between a workload platform and a cloud provider can avoid storing permanent cloud keys in the workload. The design must nevertheless validate workload provenance, namespace, service account, image, deployment context, and audience.

Workload identities should be named according to function and environment, separated between development, testing, and production, and monitored for unusual use. A service that reads a queue should not also be able to modify identity policies or create privileged users. Human users should not share service identities, because shared identities destroy attribution and complicate incident response.

Secrets Management

A secret is sensitive authentication or cryptographic material, such as a password, API key, private key, certificate, database connection string, or encryption key. Secrets management is more than placing values in an encrypted vault. It includes classification, generation, distribution, use, rotation, revocation, access logging, backup, and secure deletion.

A managed secrets service should provide encryption at rest, controlled access, audit records, versioning, and integration with applications or deployment systems. Where possible, applications should retrieve secrets at runtime through an authenticated workload identity rather than receiving them through command-line arguments or static files. Secret values should not be exposed in logs, error messages, metrics, tickets, or build output.

Rotation reduces the useful life of a compromised secret. Automatic rotation is especially valuable for database credentials, tokens, and certificates, but applications must support overlap periods and orderly replacement. Revocation is essential when compromise is suspected; rotation alone may not invalidate an already active session. Encryption keys require distinct lifecycle controls, including usage separation, custodianship, recovery, and destruction procedures.

Privileged Access Management

Privileged access can change security policy, identities, infrastructure, data, or audit evidence. Examples include modifying IAM policies, disabling logging, changing security groups, altering domain configuration, creating encryption keys, and deploying code to production. PAM is a set of technical and administrative controls for governing such access.

A mature PAM architecture typically includes a separate administrative identity, a controlled access gateway, just-in-time elevation, approval for sensitive operations, time limits, session recording where lawful and proportionate, command or action monitoring, and emergency access accounts. Administrative accounts should not be used for routine email or browsing. Privileged work should occur from hardened administrative workstations or equivalent protected environments.

Just-in-time access grants an elevated role only for an approved period and purpose. It reduces standing privilege, but it is not a substitute for sound role design. Approval workflows can become a rubber stamp if request context is poor or approvers lack independence. Emergency or “break-glass” accounts are necessary for IdP outages and recovery situations, but they should be few, strongly protected, monitored continuously, and tested without making their credentials widely known.

Credential Attacks and Privilege Escalation

Cloud identity attacks often begin with credential compromise. Password spraying tests a small number of common passwords across many accounts to avoid account lockout. Credential stuffing reuses passwords exposed in unrelated breaches. Phishing attempts to obtain passwords, session tokens, MFA approvals, or recovery information. Malware may extract browser tokens or local credentials. Attackers may also target OAuth consent, federation configuration, CI/CD secrets, service-account keys, and help-desk processes.

Detection should combine authentication and authorisation signals. Useful indicators include impossible travel, unusual device or application use, new MFA registration, abnormal token issuance, access from unfamiliar autonomous systems, sudden privilege elevation, mass data retrieval, and use of a service identity outside its normal workload. Detection must account for legitimate automation and avoid relying on a single signal.

After obtaining an initial identity, an attacker may seek privilege escalation through excessive role permissions, writable policy objects, compromised deployment pipelines, cross-account trust relationships, resource policies, or a service account that can impersonate a more powerful identity. An effective review models attack paths rather than examining permissions in isolation. For example, the combination of “modify deployment pipeline,” “deploy to production,” and “read secrets” may enable complete compromise even if no individual permission appears to be a global administrator privilege.

Permission Creep and Toxic Combinations

Permission creep occurs when access accumulates as a person changes jobs, joins projects, receives temporary exceptions, or retains historical group memberships. The risk is not merely the number of permissions. It is the mismatch between current responsibility and retained authority. Automated joiner–mover–leaver processes, expiration dates, and periodic access reviews are essential countermeasures.

A toxic combination, also known as a segregation-of-duties conflict, is a set of entitlements that should not be held together because they enable fraud, concealment, unauthorised change, or circumvention of review. Examples include the ability to create a supplier and approve payment to that supplier; modify production code and approve its own release; change IAM policy and delete audit logs; or request and independently approve privileged access.

Toxicity depends on organisational context. A permission pair that is dangerous in a financial system may be acceptable in a development sandbox. Governance teams should define conflict rules, identify compensating controls, and distinguish preventive controls from detective controls. Where separation is impossible, independent review, immutable logging, dual approval, and transaction limits may reduce—but not eliminate—the risk.

A Governance Process for Cloud Entitlements

Identity governance should operate as a continuous lifecycle rather than an annual audit event. A practical process has the following connected activities:

• establish authoritative sources for people, roles, devices, applications, and resources;
• catalogue identities, entitlements, privileged paths, and ownership;
• classify access by sensitivity, privilege, duration, and business impact;
• design role and policy models from approved tasks rather than from historical grants;
• provide request and approval workflows with business justification;
• provision access automatically where feasible and record the result;
• monitor use, anomalies, unused privileges, and policy violations;
• review access according to risk and revoke or modify it when circumstances change.

Analytics can reveal dormant accounts, unused permissions, unusual access times, privilege concentration, orphaned resources, and high-risk combinations. Entitlement analytics should not be treated as an infallible automated decision-maker. A recommendation to remove an unused permission may be wrong if the permission supports a quarterly process. Human ownership and documented exception management remain necessary.

Illustrative Case: Federation and Privilege Creep in a Multi-Cloud Enterprise

Background

Northstar Health Services, a fictional regional healthcare organisation, operates workloads in two public clouds and maintains a corporate identity directory. Its clinical analytics platform contains sensitive information, while its software teams use automated pipelines for deployment. The organisation adopted SSO rapidly but allowed cloud administrators to create direct local accounts during migration.

Situation and Problem

An internal review found that a former infrastructure engineer still belonged to a legacy cloud group. The group granted read access to production databases and membership in a deployment role. A separate inherited policy allowed the same identity to modify a pipeline configuration. MFA was enabled for the corporate account, but one local emergency account used a password stored in a shared password document. Access reviews consisted of managers approving spreadsheets without seeing effective permissions.

Analysis

The problem was not a single missing control. Federation was incomplete, identity lifecycle events were not reliably connected to cloud entitlements, and role design had grown from historical requests. The combination of pipeline modification, production deployment, and database read access created a toxic path. The emergency account was necessary in principle but was poorly governed. In addition, the review process examined individual grants rather than the combined permissions and actual owners.

Approach and Solution

Northstar made the corporate IdP the normal source of authentication and disabled unnecessary direct accounts. It retained two tightly controlled break-glass accounts with hardware-based authentication, sealed recovery procedures, alerting, and periodic tests. Administrative access was separated from ordinary user accounts and moved behind just-in-time elevation.

The organisation redesigned roles around tasks: deployment preparation, production release approval, database investigation, and identity administration were assigned to different roles. ABAC conditions restricted production access to approved devices and required stronger authentication. Workload pipelines received short-lived federated identities limited to named repositories, environments, and deployment actions. Secrets moved from pipeline variables into a managed vault, with rotation and access logging.

An entitlement inventory was created from cloud policy analysis, group membership, resource policies, and service identities. Managers reviewed business ownership and purpose, while security specialists analysed toxic combinations and attack paths. Exceptions required an expiry date, compensating control, and accountable owner.

Outcome

The fictional organisation reduced standing administrative privilege, removed dormant entitlements, improved attribution, and made emergency access observable. More importantly, it changed the governance objective from “complete the access spreadsheet” to “demonstrate that effective access is appropriate, necessary, owned, and reviewable.”

Learning Points

The case illustrates that SSO does not automatically produce secure authorisation, MFA does not correct excessive privilege, and a vault does not solve poor workload design. Effective cloud identity security requires federation, strong authentication, least privilege, lifecycle automation, policy analysis, and accountable governance operating together.

Challenges, Ethics and Professional Responsibilities

Identity programmes face tensions between security and availability, central control and team autonomy, privacy and monitoring, and operational speed and approval discipline. Excessive restrictions may encourage teams to create shadow accounts or bypass controls. Excessive convenience may create permanent privilege and weak accountability. Security architects should therefore use risk-based controls, clear service-level expectations, and usable self-service workflows.

Monitoring privileged activity can involve personal data. Organisations should define a legitimate purpose, limit collection, protect logs, control access to recordings, and comply with applicable employment, privacy, health-data, and sector regulations. Access decisions must not rely on discriminatory or irrelevant attributes. Automated analytics should be explainable enough for affected administrators and auditable by governance teams.

Cloud providers share responsibility for securing the IAM platform, but the customer generally remains responsible for configuring identities, policies, federation, keys, and logging correctly. Contracts and assurance reviews should clarify provider responsibilities, incident notification, data location, support access, and evidence availability.

Contemporary Developments and Best Practices

Passwordless authentication, passkeys, workload identity federation, policy-as-code, cloud infrastructure entitlement management (CIEM), identity threat detection and response (ITDR), and continuous access evaluation are shaping modern practice. CIEM tools analyse multi-cloud permissions and recommend least-privilege changes. ITDR correlates identity behaviour, configuration changes, and attack indicators. Policy-as-code permits access policies to be reviewed, tested, and approved through controlled development pipelines.

These technologies improve visibility but do not replace governance. Automated remediation can remove necessary access or interrupt production if context is misunderstood. Safe adoption requires dry runs, staged enforcement, rollback capability, exception handling, and measurement.

A practical best-practice baseline includes the following:

• use a resilient central IdP and phishing-resistant MFA for privileged access;
• eliminate shared human accounts and minimise long-lived access keys;
• separate human, workload, development, production, and emergency identities;
• make access narrowly scoped, time-limited, owned, and reviewable;
• analyse effective permissions and toxic combinations, not only direct grants;
• protect secrets in managed services and rotate them automatically where feasible;
• monitor authentication, privilege changes, policy changes, and sensitive data access;
• test federation failure, break-glass recovery, revocation, and incident response;
• measure dormant privilege, review completion quality, time to revoke, and privileged-session anomalies.

Chapter Summary

Cloud IAM is a security control plane that connects subjects, authentication, authorisation, resources, and accountability. Federation and SSO centralise authentication and lifecycle control but increase the importance of IdP resilience and trust protection. MFA, especially phishing-resistant authentication, reduces credential risk but must be supported by secure recovery procedures.

RBAC represents stable job functions, while ABAC applies contextual conditions. Their effectiveness depends on accurate attributes, carefully scoped policies, and analysis of effective permissions. Workload identities and short-lived credentials are safer than embedded long-lived keys. Secrets management covers the complete lifecycle of sensitive material, not merely storage. PAM limits standing administrative authority through separate accounts, approval, just-in-time elevation, monitoring, and controlled emergency access.

Credential attacks, permission creep, and toxic combinations require continuous identity governance. Entitlement management should catalogue access, establish ownership, automate lifecycle changes, analyse attack paths, and conduct risk-based reviews. Emerging tools such as CIEM, ITDR, passkeys, and policy-as-code strengthen visibility and automation, but accountable human governance remains essential.

Key Terms

Authentication: Verification of a claimed identity.

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

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

Break-glass account: A tightly controlled emergency account used during exceptional recovery situations.

CIEM: Cloud Infrastructure Entitlement Management; practices and tools for analysing and governing cloud permissions.

Federation: A trust relationship allowing one identity domain to authenticate users for another service.

Identity provider: A system that authenticates identities and issues assertions or tokens.

Just-in-time access: Privilege granted for a limited period and approved purpose.

Least privilege: Granting only the minimum necessary access for the required time and scope.

MFA: Authentication using at least two independent factor types.

OAuth 2.0: An authorisation framework for delegated access to resources.

OIDC: An identity and authentication layer built on OAuth 2.0.

PAM: Controls and processes for governing privileged accounts and activities.

Permission creep: Accumulation of access that is no longer justified by current duties.

RBAC: Access control based on roles associated with job functions.

Secrets management: Secure generation, storage, distribution, rotation, monitoring, and revocation of sensitive credentials.

SSO: A capability allowing one authentication event to provide access to multiple trusted services.

Toxic combination: Entitlements whose combination creates an unacceptable conflict or escalation path.

Workload identity: A distinct identity assigned to an application, service, pipeline, or automated process.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation and accountability.

2. Why can SSO both improve and increase security risk?

3. What is the difference between RBAC and ABAC?

4. Why are short-lived workload credentials preferable to embedded access keys?

5. Define permission creep and give one control used to reduce it.

Long Answer Questions

1. Explain how an enterprise should design federation and SSO for a multi-cloud environment, including trust, resilience, lifecycle, and monitoring considerations.

2. Compare RBAC, ABAC, and hybrid authorisation models in terms of scalability, governance, and policy complexity.

3. Describe a complete secrets-management lifecycle and explain common implementation failures.

4. Discuss the architecture and governance processes required for an effective PAM programme.

5. Explain how entitlement management can identify and remediate toxic combinations and privilege-escalation paths.

Analytical / Application Questions

1. A developer can modify a deployment pipeline, approve production releases, and read production database credentials. Analyse the toxic combination and propose a redesigned access model.

2. An organisation has enforced MFA, but an attacker compromises a help-desk recovery process and registers a new authenticator. Identify the control weaknesses and recommend layered countermeasures.

3. A cloud service account has not been used for six months but possesses permissions to modify IAM policies and access sensitive storage. Develop an evidence-based decision process for reviewing, restricting, or revoking this identity.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorisation?

A. Authentication determines permitted actions, while authorisation records events.

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

C. Authentication encrypts data, while authorisation authenticates workloads.

D. Authentication applies only to administrators, while authorisation applies only to users.

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

Question 2

What is a principal security advantage of federation and SSO?

A. It eliminates the need for an identity provider.

B. It ensures every user receives administrator privileges centrally.

C. It reduces independent passwords and supports central lifecycle control.

D. It prevents compromise of the central authentication service.

Correct Answer: C. It reduces independent passwords and supports central lifecycle control.

Question 3

Which option provides the strongest phishing resistance among the following?

A. A password delivered by email

B. A reusable SMS code

C. A push approval with no transaction context

D. A cryptographic security key or passkey

Correct Answer: D. A cryptographic security key or passkey

Question 4

An organisation wants access to depend on department, data classification, device posture, and time. Which model is most suitable?

A. ABAC

B. Basic DAC without attributes

C. Password-only access control

D. A single universal administrator role

Correct Answer: A. ABAC

Question 5

Which practice most effectively reduces risk from cloud workload credentials?

A. Embedding permanent keys in container images

B. Sharing one service account among all applications

C. Using short-lived federated workload identities with narrow scope

D. Printing credentials in deployment logs for troubleshooting

Correct Answer: C. Using short-lived federated workload identities with narrow scope

Question 6

Which activity is a core function of secrets management?

A. Publishing secrets to all developers

B. Managing generation, distribution, rotation, monitoring, and revocation

C. Replacing all authorisation policies with passwords

D. Disabling audit logs after a secret is rotated

Correct Answer: B. Managing generation, distribution, rotation, monitoring, and revocation

Question 7

Which example represents a toxic combination of entitlements?

A. Reading public documentation and submitting a support ticket

B. Viewing security logs and reporting an incident

C. Creating a supplier and independently approving payment to that supplier

D. Reading a development dashboard and receiving an alert

Correct Answer: C. Creating a supplier and independently approving payment to that supplier

Question 8

What is the main purpose of just-in-time privileged access?

A. To provide permanent administrator access to senior staff

B. To grant elevated access only for an approved, limited period

C. To eliminate the need for access reviews

D. To allow shared administrative accounts without attribution

Correct Answer: B. To grant elevated access only for an approved, limited period

Question 9

Why can a manager’s approval of a list of direct grants fail to identify actual risk?

A. Direct grants always have lower risk than inherited grants.

B. Effective permissions may also result from groups, inherited roles, and resource policies.

C. Managers are never permitted to approve access.

D. Cloud systems do not support inherited permissions.

Correct Answer: B. Effective permissions may also result from groups, inherited roles, and resource policies.

Question 10

Which response best addresses permission creep?

A. Retain all historical access for convenience.

B. Use lifecycle automation, expiry dates, ownership, and risk-based reviews.

C. Replace all roles with one broad administrator role.

D. Review access only after a security incident.

Correct Answer: B. Use lifecycle automation, expiry dates, ownership, and risk-based reviews.