Security Architecture for Hybrid Cloud

A hybrid environment has more than one control plane. There is the on-premises estate with its directory, hypervisors and firewalls. There is each cloud provider’s control plane with its own identity model, resource hierarchy and policy engine. And there is the connective tissue between them: federation, directory synchronization, private links, pipelines and secrets.

Most security architecture work concentrates on one of these at a time. Attackers do not. The practical question for an architect is which of these planes is authoritative for identity, for policy and for evidence, and what happens when they disagree or when one is compromised.

The NSA’s cloud mitigation guidance reflects the same emphasis. Among its ten strategies are respecting the division of duties between provider and customer, managing cloud identities and access, segmenting and encrypting cloud networks, protecting pipelines and infrastructure-as-code, addressing hybrid and multi-cloud complexity, and keeping cloud logs usable for threat hunting. Most of them are about seams rather than individual services.

The seams where hybrid architecture breaks

NIST’s access control guidance for cloud systems explains why the responsibility row matters. Each delivery model requires managing different types of access on the service components it offers, and the guidance builds up from infrastructure through platform to software as a service. A single statement that “the provider secures the cloud” cannot describe that, and it leaves gaps that surface during an audit or an incident.

Design choices and their trade-offs

How many identity authorities

One identity provider across all environments simplifies governance and lets policy follow the user. It also concentrates risk: a compromise of that provider affects everything. Separating administrative identities for the most sensitive environments reduces that blast radius at the cost of more accounts to manage. Which way to lean depends on how much operational friction the administrators will tolerate and how well the identity provider itself is hardened and monitored.

Where the security boundary sits in the cloud

Account, subscription or project structure is a security boundary as much as a billing one. Separating production from non-production, and isolating the environments that hold sensitive data, limits what a single compromised credential can reach. The trade-off is operational overhead and the need for organization-level guardrails that apply policy consistently, so that new accounts do not start with weaker settings than old ones.

Common policy or native tooling

Many teams want one policy language across every environment. A common layer gives consistency and one place to audit. It can also hide provider-specific controls that matter, and it adds a component that has to be maintained. A pragmatic pattern is a common policy intent expressed once and enforced through each provider’s native mechanisms, with the mapping reviewed regularly.

How far to extend the network

The easy design extends the corporate network into the cloud. It is also the design that turns one compromised endpoint into reach across both environments. Guidance on zero trust for cloud-native applications points toward policy enforced by application and service identity, independent of whether a workload runs on-premises or in one of several clouds. Even where a full identity-based model is not yet possible, segment the connection and keep the default posture closed.

Whether hybrid is a destination or a transition

Hybrid is often described as a stage on the way to cloud and then becomes permanent by default. CISA’s microsegmentation guidance cautions against lift-and-shift migrations and recommends cloud-native designs instead. If a legacy control is carried across unchanged, plan its retirement path and owner at the same time, or the estate will accumulate two sets of controls that each assume the other is doing the work.

What a hybrid cloud architecture review should find

A review is only useful if it tests the seams directly. These questions are a good starting set.

• If the on-premises directory were compromised today, could the attacker obtain administrative access to any cloud tenant, subscription or project?

• Which identities, human and non-human, can change IAM, routing or logging configuration in each environment, and how is each protected?

• Do private links allow any-to-any routing between environments, or only defined paths?

• Can an analyst search control plane activity and workload logs from every environment in one place, with a common identity field?

• Is there a responsibility matrix by service, and does someone own the SaaS applications that hold sensitive data?

• Which pipelines can deploy to production, with what rights, and who reviews changes to them?

• If a region, a provider or a connectivity link fails, do security controls fail open or fail closed, and was that a deliberate decision?

Answers that begin with “we assume” or “the provider handles” mark the places to look first.

What to do next

Start with the identity and connectivity questions above and map the answers against each environment. A configuration review scoped to those seams, rather than to each platform in isolation, usually shows within a short time where an architecture is relying on assumptions. If your cloud footprint has grown through acquisitions, migrations or separate business unit decisions, that review is the logical first step toward a single architecture you can defend.

Sources

1. NSA Releases Top Ten Cloud Security Mitigation Strategies. National Security Agency, with CISA support on part of the series

2. NIST SP 800-210, General Access Control Guidance for Cloud Systems. National Institute of Standards and Technology

3. NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. National Institute of Standards and Technology

4. Microsegmentation in Zero Trust, Part One: Introduction and Planning. Cybersecurity and Infrastructure Security Agency. Source for the guidance on lift-and-shift migrations