Multi-Cloud Security: Managing Risk Across Platforms

Very few organisations chose to be multi-cloud. They acquired a company running somewhere else, bought a SaaS product hosted elsewhere, let a research group open an account for a grant, or adopted a second provider for one service that was better there. The result is the same: several clouds, each configured differently, most of them understood by one or two people.

Decide whether it is deliberate

Multi-cloud has real justifications — resilience, avoiding lock-in, a service only one provider offers, regulatory requirements, inherited estates. It also has real costs, and they are mostly human.

If it is not deliberate, consolidating is often the better security investment. One well-run cloud beats three partly-understood ones, and the migration cost is frequently lower than the ongoing cost of maintaining expertise across all of them.

Consolidate identity first

The single highest-value multi-cloud control is one identity provider federating to all of them.

Without this, offboarding requires remembering every provider — and the one nobody remembers is the one the departing engineer set up.

Normalise posture, accept the differences

Each provider names things differently and implements similar controls in dissimilar ways. Trying to force identical configurations wastes effort; the goal is equivalent outcomes, measured consistently.

Use a single cross-cloud posture tool where you can, so one dashboard answers "is public storage blocked everywhere" without three separate consoles and three vocabularies.

The expertise problem

This is the real constraint and it is rarely budgeted. Each provider is a specialism. A team that is genuinely strong in one is usually adequate at the second and guessing at the third — and guessing produces the misconfigurations that cause incidents.

Options, honestly:

• Consolidate to fewer providers
• Concentrate expertise — name an owner per cloud rather than expecting everyone to cover all
• Buy the gap — managed services or a partner for the cloud you are weakest in
• Restrict what runs where — the cloud you understand least hosts the least sensitive workloads

That last one is underused and costs nothing. If a research group's GCP account is the least well understood, it should not be where PHI lives.

Logs and the paths between clouds

Two problems appear only once workloads genuinely span providers.

Log consolidation. Each cloud emits audit logs in its own format, to its own service, with its own default retention — which in at least one case is shorter than any healthcare retention obligation. Investigating an incident that crosses providers means pivoting between three consoles and three vocabularies while the clock runs. Ship all of them to one place, normalise the fields that matter (identity, source address, action, resource) and set retention centrally. See logging strategy.

The connections between them. Traffic crossing providers leaves each one's network. Egress cost usually gets the attention; the security question is whether that path is encrypted, authenticated and logged at both ends. Peering and VPN links set up during a migration have a habit of outliving it, and a permanent tunnel between two clouds is a lateral movement path that appears on neither provider's diagram.

Where to start

List every cloud account your organisation pays for, including departmental and research ones, and check which are federated to your identity provider. The unfederated ones are where the risk concentrates, and expense data will find accounts no inventory has.

GuardsArm assesses multi-cloud posture and identity consolidation. Book a scoping call.