Executive Summary

This architecture solves fragmented identity and access control across a growing multi-cloud estate. The organisation needs to enable product teams and cloud engineers to deploy workloads across Azure and AWS while maintaining consistent access governance, privileged access control, auditability, and security monitoring.

The architecture enables secure multi-cloud scalability by establishing Microsoft Entra ID as the central workforce identity control plane, federating access into AWS and Azure, enforcing least privilege, separating human and workload identities, and centralising security telemetry into Microsoft Sentinel.

The intended outcome is a standardised multi-cloud landing zone where identity, access, privilege, workload deployment, monitoring, and governance are consistently enforced across Azure and AWS.

Business Context

This organisation is a highly regulated fintech company that fulfils transactions and requires 24x7x365 availability for a global customer base. It has acquired a smaller technology firm using Azure while the parent organisation primarily uses AWS. This creates a strategic requirement for a secure identity-first multi-cloud environment.

The cloud estate hosts the trading platform, supporting technology, API management, databases, logging, monitoring, and security services. The acquisition creates an opportunity to reduce reliance on a single cloud provider while improving availability, resilience, and governance.

Users in Scope

IT Admins Platform Engineers Platform Admins Clients Prospective Clients External Contractors Sales Teams Auditors

Business Events That Trigger Access

Access is triggered by client onboarding, cloud environment management, production support, workload deployment, audit review, privileged administration, incident response, and acquisition integration activity.

Problem Statement

Prior to this design, the fintech company’s IAM deployment was highly reliant on AWS, creating vendor lock-in and resilience risk. The acquisition introduced a second cloud estate in Azure, resulting in duplicated identity management, inconsistent role structures, fragmented privileged access, separate logging models, and duplicated account governance.

The fragmented identity practices created two trust systems, two lifecycle systems, two privilege systems, two audit systems, and two control planes. This reduced visibility into enterprise-wide identity risk and increased the likelihood of orphaned access, entitlement mismatch, and lateral movement across cloud environments.

Core security gap: absence of a consistent identity-led multi-cloud operating model.

Architecture Objectives

Objective	Architecture Intent
Central identity control plane	Create a single identity authority for AWS, Azure, and future cloud platforms.
Secure workforce access	Enable seamless authentication while preventing unmanaged local cloud users and identity sprawl.
Privileged access governance	Prevent standing privileged access through JIT/PIM workflows and approval-based elevation.
Workload identity separation	Separate human and machine identities to reduce blast radius and improve traceability.
Cross-cloud detection	Detect risky sign-ins, unusual privilege activation, suspicious API activity, and cloud credential compromise across AWS and Azure.
Business continuity	Preserve engineering productivity, deployment velocity, regulatory evidence, and multi-cloud resilience.

Scope and Assumptions

Systems in Scope

Microsoft Entra ID Azure Subscriptions AWS Accounts AWS IAM Identity Center Azure RBAC AWS IAM Roles Privileged Access Management CI/CD Platforms Secrets Management Cloud Logging Microsoft Sentinel

Assumptions

The architecture assumes Entra ID remains the authoritative workforce identity control plane, cloud provider federation is correctly configured, users are lifecycle-managed, device posture signals are reliable where used, and cloud-native IAM policies are consistently governed.

Dependencies

Dependencies include Entra ID availability, Azure and AWS federation, lifecycle provisioning, CI/CD integration, privileged access workflow availability, Sentinel telemetry ingestion, cloud-native audit logging, and security operations response capability.

Architecture Overview

Users authenticate through Entra ID. Entra federates workforce access into Azure and AWS. Azure access is enforced through Azure RBAC, management groups, subscriptions, and PIM. AWS access is enforced through AWS IAM Identity Center, permission sets, roles, and account boundaries.

Workload identities are handled separately through managed identities, service principals, IAM roles, and short-lived credentials. Telemetry from identity, cloud control planes, CI/CD, workload identity, and privileged access flows into Sentinel for correlation.

Architecture Area	Design Position
Core systems	Entra ID, AWS IAM Identity Center, Azure RBAC, AWS IAM roles, Azure subscriptions, AWS accounts, CI/CD, workload identities, cloud logging, Sentinel.
Trust boundaries	User-to-IdP authentication, IdP-to-cloud federation, privileged role activation, CI/CD-to-cloud deployment, workload-to-resource access, and telemetry ingestion.
Control points	Authentication, Conditional Access, federation trust, role assignment, JIT activation, cloud policy, workload identity issuance, secrets access, and logging.
High-level access model	Centralised identity, federated cloud access, least-privilege roles, JIT privilege, workload identity separation, central logging, and governance review.

Identity, Access and Trust Model

Model	Architecture Position
Identity Flow	Human identities are established in Entra ID using HR-driven lifecycle processes or controlled guest/partner onboarding. Acquired-company users are migrated, federated, or represented as external users during transition.
Authentication	Users authenticate through Entra ID using strong authentication, with phishing-resistant MFA/passwordless preferred. Conditional Access evaluates risk, device posture, location, and role sensitivity.
Access Model	RBAC provides baseline cloud roles, ABAC provides contextual restriction where supported, and policy-based controls enforce Conditional Access and cloud governance.
Privileged Access	Privileged roles are eligible but inactive by default. Activation requires justification, MFA, approval where required, time-bound access, and audit logging.
Trust Model	Trust is based on identity validity, authentication strength, user/sign-in risk, device posture, role entitlement, environment sensitivity, and session behaviour.

Threat Model

Major attack paths include compromised workforce identity leading to cloud console access, token theft enabling role assumption, excessive permissions enabling privilege escalation, compromised CI/CD pipelines, workload identity abuse, secrets theft, local cloud user bypass, and stale access after team or project changes.

Threat Area	Risk Introduced
Authentication boundary	Credential theft, MFA fatigue, user risk compromise.
Federation boundary	Misconfigured trust, excessive claims, role mapping errors.
Cloud control plane	Overprivileged access, destructive changes, persistence creation.
Workload identity	Service principal abuse, IAM role misuse, secrets exposure.
CI/CD boundary	Pipeline compromise and unauthorised deployment.
Logging boundary	Telemetry gaps and delayed detection.

Control Strategy

Control Type	Controls
Preventive	Entra ID, Conditional Access, phishing-resistant MFA, Azure RBAC, AWS permission sets, JIT/PIM, least-privilege IAM roles, cloud guardrails, workload identity separation, secrets management, CI/CD deployment controls.
Detective	Entra Identity Protection, Azure Activity Logs, AWS CloudTrail, AWS GuardDuty, Microsoft Defender for Cloud, privileged access logs, CI/CD audit logs, anomalous API activity detection, Sentinel correlation.
Response	Session revocation, privileged role deactivation, permission removal, account suspension, cloud role revocation, secret rotation, pipeline disablement, resource quarantine, policy enforcement, incident escalation.
Recovery	Break-glass cloud administration, account recovery, cloud configuration rollback, infrastructure-as-code redeployment, backup restoration, secret rotation, workload recovery, entitlement revalidation.

Architecture Decision Log

Decision	Rationale	Trade-Off	Residual Risk
Use Entra ID as central workforce identity provider	Provides centralised authentication, Conditional Access, lifecycle integration, MFA/passwordless support, Azure-native integration, and AWS federation.	Creates dependency concentration around Entra ID.	IdP compromise, Conditional Access misconfiguration, tenant-level dependency.
Use federation into AWS and Azure	Reduces credential sprawl, improves lifecycle control, centralises authentication, and simplifies auditability.	Federation configuration must be carefully governed.	Misconfigured role mappings, token misuse, excessive permission sets.
Avoid local cloud users by default	Prevents bypass of central lifecycle and identity governance.	Requires reliable federation and emergency access design.	Break-glass accounts must be protected and monitored.
Use JIT/PIM for privileged access	Reduces standing privilege and improves accountability.	Introduces approval and activation friction.	Approver compromise or activation misuse.
Separate human and workload identity	Reduces blast radius, improves traceability, supports short-lived credentials, and strengthens least privilege.	Requires mature identity and secrets governance.	Overprivileged service principals or weak workload trust policies.
Centralise logging in Sentinel	Improves correlation of identity-to-cloud attack chains and supports audit reconstruction.	Requires ingestion cost management and detection tuning.	Telemetry gaps and alert fatigue.
Standardise landing zone patterns	Reduces misconfiguration, accelerates secure delivery, and improves governance consistency.	Requires platform engineering effort and governance discipline.	Teams may bypass platform patterns if friction is too high.

Monitoring, Response and Recovery

Detection Architecture

Monitoring covers Entra authentication, Conditional Access, privileged activations, AWS IAM Identity Center, Azure RBAC, AWS CloudTrail, Azure Activity Logs, CI/CD deployments, workload identity activity, secrets access, policy violations, and cloud posture findings.

Incident Response

When risk increases, access posture is degraded through step-up authentication, session revocation, privileged role removal, permission restriction, temporary blocking, or additional approval.

Recovery Model

Access is restored through identity revalidation, entitlement review, policy reevaluation, role reassignment, and issuance of new trusted sessions after risk resolution.

Break-Glass

Break-glass applies when Entra ID, federation, Conditional Access, privileged access workflows, or normal cloud administration paths become unavailable, misconfigured, or compromised.

Risk, Assurance, Audit and Governance

Risk Register

Residual risks include Entra ID compromise, federation misconfiguration, overprivileged cloud roles, workload identity abuse, CI/CD compromise, alert fatigue, cloud logging gaps, misconfigured landing zone policies, and acquired-company identity hygiene weaknesses.

Assurance Model

Control effectiveness is validated through policy outcomes, access reviews, privileged activation logs, cloud role reviews, cloud security posture findings, identity risk trends, audit log completeness, incident response metrics, and periodic control testing.

Audit Model

The audit trail should show who accessed which cloud environment, from where, on which device, through which identity path, under which role, what action they performed, and whether the action was approved, detected, or remediated.

Governance Model

Identity controls are owned by the identity/security team. Cloud access controls are jointly owned by cloud platform engineering and security. Workload identity controls are owned by platform engineering. Logging and detection are owned by security operations.

Trade-Off Register

Trade-Off	Security Benefit	Business / Operational Cost
Federated access across Azure and AWS	Preserves delivery speed while centralising workforce identity.	Creates dependency on federation quality and role-mapping accuracy.
JIT privileged access	Reduces standing privilege.	Adds approval and activation friction.
Multi-cloud operating model	Reduces single-cloud dependency and supports acquisition integration.	Increases governance, detection, and policy maintenance complexity.
Centralised Entra identity	Improves consistency and auditability.	Concentrates dependency on Entra and Conditional Access configuration.
Standard landing zones	Improves control consistency and reduces misconfiguration.	May reduce team autonomy where bespoke configurations are requested.

Future State / Version 2

Question	Architecture Evolution
What would improve next?	Stronger phishing-resistant authentication coverage, granular entitlement modelling, automated cloud access certification, mature workload identity governance, and stronger acquisition integration patterns.
What would be automated next?	Automatic deprovisioning at project closure, automatic expiry of temporary cloud access, cloud role review reminders, Sentinel incident creation, misconfiguration remediation, and CI/CD policy enforcement.
What would be strengthened next?	Workload identity posture, service principal governance, secrets rotation, CI/CD pipeline access, cloud-native policy guardrails, break-glass monitoring, production access approvals, and cross-cloud detection rules.
What would be removed next?	Local cloud users, shared admin accounts, long-lived access keys, standing privileged roles, manually managed entitlements, unmanaged cloud accounts, embedded secrets, and ad hoc cloud environments.

Architecture evolution principle: Version 2 should reduce identity fragmentation, minimise standing privilege, improve workload identity assurance, automate lifecycle governance, and strengthen detection of identity-led attacks across cloud control planes.

Identity-Centric Multi-Cloud Landing Zone Architecture