Multi-Cloud Identity Guide: AWS, Azure and Google Cloud

Running AWS, Microsoft Azure and Google Cloud side by side means running three identity and access management models with different hierarchies, role languages, privilege escalation paths and logs, and attackers only need the weakest of the three. Multi-cloud identity management is the discipline of making those models behave as one: a single source of workforce identity, consistent least privilege, guardrails enforced in every cloud, and one inventory that correlates every human and non-human identity across them. This guide covers identity federation across clouds, cross-cloud privilege governance and just-in-time access, policy enforcement, identity sprawl and drift, and how cloud identity takeover happens and is detected. It is written for cloud security architects, identity teams and platform engineers who own more than one cloud estate.

Key takeaways

• One workforce identity source, federated everywhere. Authenticate people once in a central identity provider and federate into each cloud; local cloud users and per-cloud passwords are where sprawl and takeover start.
• Least privilege must be translated, not copied. The same job function maps to different roles, scopes and escalation-sensitive permissions in each cloud, so define access by function and implement it per cloud.
• Standing privilege is the biggest single risk. Use Entra Privileged Identity Management, Google Cloud Privileged Access Manager and approval-based assignment on AWS so administrative roles exist only when needed.
• Guardrails sit above identities. AWS service and resource control policies, Azure Policy at management group scope, and Google organisation policies and IAM deny policies cap what any identity can do, even a misconfigured one.
• You cannot govern what you cannot correlate. Join every cloud principal to an owner and an authoritative identity, and treat unowned, unused and orphaned identities as findings.

Why multi-cloud identity is hard

Cloud identity and access management in each provider was designed in isolation. AWS organises accounts under AWS Organizations and grants access through IAM roles and policies. Azure places subscriptions under management groups and relies on Microsoft Entra ID for identities and Azure role-based access control (RBAC) for permissions. Google Cloud nests projects under folders and an organisation, with IAM allow and deny policies. A multi-cloud IAM programme has to reconcile three sets of answers to the same questions.

The result, left unmanaged, is cloud identity sprawl: local IAM users created for a quick fix, guest accounts in a second tenant, service accounts nobody owns, and federation trusts configured once and never reviewed. Each cloud's security guide goes into its own model; see the AWS Security Guide, the Microsoft Azure Security Guide and the Google Cloud Security Guide.

Identity federation across clouds

The foundation of multi-cloud access management is one authoritative identity provider for the workforce, federated into every cloud, with joiner, mover and leaver events driving access in all of them at once.

• AWS: IAM Identity Center connects an external identity provider and assigns permission sets across accounts. AWS describes the organisation instance, deployed in the management account, as best practice and the only instance type that manages access to AWS accounts; permission sets are available only there. With a SAML provider you federate once and manage one certificate.
• Google Cloud: Workforce Identity Federation lets users of an OIDC or SAML 2.0 provider such as Entra ID sign in without syncing accounts into Google. Workforce pools are configured at organisation level, google.subject should be an immutable value, and users in more than 400 groups fail to sign in when groups are mapped. Workforce principals cannot reach resources outside their organisation directly, but service account impersonation can bypass that, so impersonation rights need review.
• Azure: Entra ID is the native identity plane. Where Entra ID is also the workforce provider for the other clouds, its Conditional Access, phishing-resistant authentication and PIM become controls for all three.

Whichever hub you choose, harden it as the most privileged system you own. The Identity Provider and SSO Security Guide covers this in depth, and the Snowflake breach shows what happens when cloud service accounts accept passwords without MFA.

Hybrid cloud identity

Most estates also synchronise on-premises Active Directory into Entra ID, which makes on-premises compromise a route into the cloud. ATT&CK notes that federated or synced accounts may be a pathway between on-premises and cloud systems. Microsoft's guidance on protecting Microsoft 365 from on-premises attacks is the reference model for hybrid and multi-cloud governance:

• Cloud-only administrators: use cloud-only accounts for privileged roles; no on-premises account should hold cloud administrative privileges, and synchronised objects should hold no privileges beyond a standard user.
• Federation dependency: Microsoft recommends disabling federation trust relationships for authentication where possible, because anyone holding a compromised SAML token-signing certificate can impersonate any user. The SolarWinds compromise used forged SAML tokens.
• Tier 0 sync infrastructure: monitor hybrid identity servers, including Entra Connect, as tier-0 systems. The Storm-0501 attacks used stolen Entra Connect Sync credentials to move from on-premises into the cloud.

Cross-cloud workload identity and access

Non-human identities usually outnumber people in each cloud, and cross-cloud access is where static keys survive longest: an AWS workload holding a Google service account key, or a pipeline holding secrets for all three clouds. The rule is the same everywhere: native identities for workloads inside a cloud, and workload identity federation for cross-cloud access, with each trust pinned to a specific issuer, subject and audience. The Cloud Workload Identity Guide explains roles, managed identities, service accounts and federation per cloud.

Two multi-cloud specifics matter for governance. First, a federation trust is an access grant written in another team's configuration language, so the owner of the target cloud must review trusts created for workloads in the source cloud. Second, identity boundaries do not always match project boundaries: Google treats the same Kubernetes namespace and service account in any GKE cluster of a project as one identity, so clusters of different trust levels belong in different projects.

Cross-cloud privilege governance

Multi-cloud least privilege and authorisation

Define access in business terms (job functions and workload purposes), then implement each function per cloud: an AWS permission set, an Azure role assignment at the narrowest scope, a Google predefined or custom role on a folder or project. Do not treat the clouds' built-in "Owner" or "Administrator" roles as equivalent; their scope and reach differ. Basic roles such as Google's Editor and broad subscription-level Owner assignments should be exceptions with named owners.

Multi-cloud authorisation reviews must give extra weight to permissions that let one identity become another or grant itself more access:

ATT&CK records Storm-0501 using elevateAccess and roleAssignments/write to gain User Access Administrator and Owner roles (T1098.003 Additional Cloud Roles). The Cloud PAM and CIEM Guide covers entitlement analysis tooling categories.

Multi-cloud standing privilege and JIT access

Multi-cloud JIT access means administrative roles in every cloud are eligible rather than permanently active, and each activation is logged against the correlated identity.

• Azure: PIM turns active role assignments into eligible ones that require activation with MFA, justification and optional approval, time-bound, with notifications and access reviews. PIM requires additional Entra licensing. Alert on direct privileged assignments made outside PIM.
• Google Cloud: Privileged Access Manager uses entitlements that define requesters, roles, maximum duration, justification and approvers, and removes the roles automatically when the grant ends. Legacy basic roles (Owner, Editor, Viewer) are not supported, and manual edits to bindings it manages can conflict with it.
• AWS: build time-bound access by adding and removing IAM Identity Center account assignments through an approval workflow, and keep role session durations short.
• Break-glass: keep a small number of monitored emergency accounts per cloud, excluded from JIT but alerted on every use. See the JIT Access Guide.

Cross-cloud policy enforcement

Guardrails cap the maximum permissions available in a part of the hierarchy, so a mistake in one role cannot exceed them. None of them grant access.

• AWS SCPs and RCPs: AWS uses SCPs to limit IAM principals in member accounts and RCPs to restrict principals external to the organisation accessing resources such as S3 buckets, KMS keys, Secrets Manager secrets and STS. Neither affects the management account, service-linked roles are exempt from RCPs, and AWS strongly recommends testing before attaching an RCP to the organisation root.
• Azure Policy: assign deny policies at management group scope so they inherit to every subscription. Policies can block identity-relevant resources directly, for example federated identity credentials on managed identities outside approved subscriptions.
• Google organisation policies and deny policies: constraints such as iam.disableServiceAccountKeyCreation block risky configurations, and IAM deny policies are checked before allow policies, attach to the organisation, a folder or a project, and support exception principals.

Express guardrails as code in one repository with a shared control objective per row (for example "no long-lived keys", "no external sharing of secrets", "no role grants outside the identity team") and an implementation per cloud. This is the practical core of zero trust for multi-cloud environments: NIST SP 800-207A describes access control based on application and service identities, enforced irrespective of where services run, rather than on network location. See the Zero Trust Identity Guide.

Identity sprawl, drift and correlation

• Cloud identity sprawl: the uncontrolled growth of identities, credentials and trusts across clouds, tenants and accounts.
• Cloud identity drift: the gap between intended and actual identity configuration, such as a role edited in the console after deployment from code. Hybrid and multi-cloud access drift is the same gap in entitlements: access granted for a project and never removed, or a mover keeping access in one cloud after it was removed in another.
• Phantom cloud identity: an identity that still exists and can authenticate but has no owner, no active workload or no matching authoritative identity, such as role assignments left after a managed identity is deleted, keys for departed contractors, or an account in a forgotten test tenant. The Midnight Blizzard breach began in exactly such a test tenant.
• Cross-cloud identity correlation: joining each cloud principal (an IAM Identity Center user, an Entra object ID, a Google principal identifier, a workload role or service account) to one authoritative person or owning team, using immutable identifiers rather than display names or email addresses.
• Cloud identity fabric: an architecture that puts a common inventory, policy and analytics layer over several identity providers and clouds, rather than another directory. Whether built or bought, its value depends on that correlation. See the Identity Data Quality Guide.

Native tooling helps measure drift. IAM Access Analyzer reports unused roles, unused access keys and passwords, and unused service and action permissions at account or organisation scope, plus external access through resource policies. Azure PIM access reviews and Google role recommendations cover the equivalent ground.

Cloud identity takeover and abuse

Cloud identity takeover rarely needs an exploit. The recurring routes are stolen passwords where MFA is not enforced, stolen session tokens, credentials obtained from a compromised workload, and social engineering of a help desk. The Capital One breach retrieved a firewall's role credentials, and the Bybit hack used a developer's AWS session tokens. Cloud identity abuse then follows a familiar pattern: valid cloud accounts (ATT&CK T1078.004), added credentials for persistence (T1098.001) and added roles for escalation (T1098.003).

Feed all three clouds into one detection pipeline keyed on the correlated identity, so a session that pivots from Entra ID into AWS through federation is seen as one actor. The ITDR Guide covers detection engineering.

Implementation roadmap

1. Inventory: list every human and non-human identity, credential, federation trust and privileged assignment in all three clouds and every tenant, including sandboxes and test tenants.
2. Choose the hub: decide the authoritative workforce provider and federate it into IAM Identity Center, Google Workforce Identity Federation or Cloud Identity, and Entra ID. Pilot with one team before migrating local users.
3. Remove local access: disable IAM users with console passwords, local Google accounts and stale guests once federated access is proven. Keep break-glass accounts.
4. Apply guardrails in audit mode first: evaluate Azure Policy with the audit effect, test SCPs and RCPs on a test organisational unit and review CloudTrail access denied events, and apply Google constraints to a test folder first. Roll back by detaching the policy.
5. Remove standing privilege: convert permanent administrator assignments to PIM eligibility, Google PAM entitlements and approval-based AWS assignments, starting with the most privileged roles.
6. Federate workloads: replace cross-cloud keys with federation, deactivating keys before deleting them.
7. Correlate and review: join every principal to an owner, run quarterly access reviews per function across clouds, and remove unused access found by native analysers.

Decision guidance

• Small organisations: one cloud is usually primary. Use its identity provider as the hub, keep the second cloud minimal and federated, and rely on native JIT and guardrails rather than a cross-cloud platform.
• Large organisations: a central identity team should own the hub, guardrails and privileged access in all clouds, while platform teams own workload identities within those guardrails. A cross-cloud entitlement and inventory layer becomes worthwhile once manual correlation cannot keep up.
• Centralised versus delegated administration: centralise anything that grants access (role assignment, policy, federation trusts); delegate resource administration within scoped roles.
• Mergers and acquisitions: federate the acquired estate into the hub first, apply guardrails second, and migrate identities last.

Detection and measurement

Centralise CloudTrail organisation trails, Entra sign-in and audit logs with the Azure Activity Log, and Google Cloud Audit Logs (with Data Access logs enabled for IAM and Security Token Service) in one store with a shared identity key. Metrics:

• Federated coverage: percentage of human cloud access through the central provider (target 100% outside break-glass).
• Standing privileged assignments: count of permanent owner or administrator-level assignments per cloud, trending to zero.
• Unused access: roles, keys and permissions unused for 90 days, and time to remove them.
• Uncorrelated identities: principals with no owner or authoritative identity.
• Guardrail coverage: share of accounts, subscriptions and projects under the full guardrail set.
• Leaver closure time: time from leaver event to removal of access in every cloud.

Framework mapping

Common failure patterns

• A second cloud outside the hub: local users with passwords and no MFA in the "smaller" cloud.
• Synced privileged accounts: on-premises administrators holding cloud roles, so domain compromise becomes cloud compromise, as in the Storm-0501 attacks.
• Forgotten tenants and accounts: sandboxes and test tenants outside guardrails and monitoring, as in Midnight Blizzard.
• Guardrails with broad exemptions: exemptions granted for a migration and never removed.
• Help desk resets for cloud administrators: the Storm-2949 attack turned one reset Entra ID account into a cloud-wide breach.
• Escalation rights treated as routine: iam:PassRole, role assignment rights and service account impersonation granted to developer roles by default.

Practitioner checklist

• Pick one authoritative workforce identity provider and federate it into every cloud; remove local cloud users except break-glass.
• Use cloud-only accounts for cloud administration and keep synced objects unprivileged.
• Convert standing administrator access to PIM, Google PAM and approval-based AWS assignments.
• Review escalation-sensitive permissions in every cloud as privileged access.
• Apply SCPs, RCPs, Azure Policy and Google organisation and deny policies from one guardrail repository, tested in audit mode first.
• Replace cross-cloud keys with workload identity federation pinned to exact subjects.
• Correlate every principal to an owner using immutable identifiers, and investigate phantom identities.
• Centralise all cloud identity logs with a shared identity key and alert on credential, role and guardrail changes.
• Measure federated coverage, standing privilege, unused access and leaver closure time monthly.

Standards and references

• NIST: SP 800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• MITRE ATT&CK: Valid Accounts: Cloud Accounts (T1078.004)
• AWS: What is IAM Identity Center?
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
• Microsoft Learn: Protecting Microsoft 365 from on-premises attacks
• Google Cloud: Workforce Identity Federation
• Google Cloud: Privileged Access Manager overview

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Cloud PAM and CIEM Guide · JIT Access Guide · Zero Trust Identity Guide · Cloud Security Guide