Home / Knowledge hub / Multi-cloud security
Knowledge hub
Multi-cloud security
Keeping controls consistent when you run across more than one cloud provider.
What it means
Multi-cloud means using more than one cloud provider at once, perhaps one for your main app, another for data analysis and a third because a customer asked for it. Multi-cloud security is keeping the same standard of protection across all of them.
Each provider names things differently and builds its identity, networking and logging in its own way. The same intention, such as a private storage bucket or a limited role, needs different settings on each. Gaps appear in the translation. Good intent does not carry across on its own.
Why it matters
More platforms mean more places for a misconfiguration to hide, and fewer people who know all of them well. A rule checked carefully on one provider may be skipped on another. Logs end up in different formats and places, so an incident takes longer to piece together.
Under the shared responsibility model, the provider secures its platform and you secure what you put on it, on each one separately. Customers and auditors will ask for evidence across all of them, not the best of them. Gaps in one place are gaps in all.
How it shows up
You meet it when teams adopt tools one by one, after an acquisition, or to meet data location rules. The common problems are different access models for each provider, inconsistent naming and tagging, secrets kept in several managers, and no single list of what is running where.
Start by standardising what you control: one identity approach with least privilege, one place for logs, written baselines for each provider, and infrastructure as code so settings are reviewable. Then test the running apps on each platform in the same way, as the flaws often differ.
Questions people ask
Multi-cloud security, answered
Is multi-cloud more secure than one cloud?
Not by itself. It can reduce dependence on one provider, but it also adds more settings to get right. Security depends on how consistently you manage each.
Spread out without a standard and the risk goes up.
What should we standardise first?
Identity and access, logging, and the baseline settings for storage and networks. These cause most of the serious gaps, and they are easy to compare between providers.
Then add an inventory of what runs where.
Do we need a special tool?
Some teams use cloud posture management tools that read settings from several providers. They help with visibility, but a tool cannot decide your policy for you.
Write the standard first, then check against it.
Does the shared responsibility model change per provider?
The idea is the same, but the exact split depends on the service. A virtual machine, a managed database and a serverless function each leave you with different duties.
Read each provider's documentation for each service.
How do we test across clouds?
Test the application itself on each platform the same way, and review each account's settings against your baseline. The same app can behave differently on different infrastructure.
Keep one record of the results.
Related
Terms that sit next to this one
Cloud misconfiguration
A cloud setting left unsafe, such as open storage or an overly broad permission.
Shared responsibility model
The split between what your cloud provider secures and what you must secure yourself.
Infrastructure as code
Describing servers and networks in files so they can be reviewed and repeated.
CSPM
Tools that keep checking your cloud settings against security good practice.
Public cloud
Computing rented from a provider that shares its hardware across many customers.
Is the app the same on every cloud?
We test the running application and its APIs wherever they are hosted, and report what we proved, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.