I got asked a question… this gives me a chance to write an opinion. I have lots of them!
Is it reasonable to just stick with a single cloud provider, or is it better to go multi-cloud?
It think it seems reasonable. I expect very few places are true multi-cloud, as in a given app runs in two clouds. That becomes challenging if trying to use cloud native services ‘cos how you access RDS would be different to how you access Azure SQL, so writing a true multi-cloud application isn’t so simple. Especially when you start to do Infrastructure as Code (IaC) where your Terraform templates may be totally different; “why does this work in AWS but not Azure?!”
And if you try to avoid that by basically self-hosting everything (just using the IaaS) then you avoid many of the benefits of cloud (you’re just outsourcing your datacenter) and might as well stick with a provider of choice, for simplicity.
Businesses that are multi-cloud would tend to have App1 in AWS, App2 in Azure, App3 in GCP…
We’ve made it simple for app teams (they just target a simple cloud) but this becomes a headache to secure because structures work differently between CSPs; IAM processes are different, auditing and reporting is different, firewalls/WAFs are different. Even things which may seem simple are different. Even VPC can mean different things between providers!
It’s not to say you can’t go multi-cloud for a single app (and handle data gravity issues and so on), but my feeling is that these are more the exception than the rule.
Every cloud provider you use may require a whole new set of tooling to manage it.
Note: this ignores SaaS offerings like Microsoft Office 365, or Workday or and the like. I suspect everyone is multi-cloud when you take SaaS into account :-)
what about a hybrid cloud with a solution that bridges into public cloud providers so that they are basically one cloud everywhere, even on-prem. Isn’t that insecure?
Just because there’s connectivity, it doesn’t mean that there are no blast radius limitations. After all, even for pure public cloud hosted apps you’re going to need connectivity back to on-prem (eg via ExpressRoute or DirectConnect or whatever) just because your cloud-hosted app will need to talk to on-prem resources to function. Your core processing and orchestration systems may be on-prem and your app may have dependencies on them. Until you go 100% cloud there will be a requirement for communication between on-prem and the cloud.
How you limit your blast radius will depend on how far you want to go.
For example, in AWS, you could use VPCs as a form of macro-segmentation, and have an app per VPC. For traffic to leave a VPC it has to traverse a firewall where it is inspected and only authorised destinations (whether that’s another VPC or on-prem or even the mainframe). Azure provides similar constructs. You could consider this a “hub and spoke” model; all communication between spokes has to go via the hub and this becomes a good control point.
This isn’t micro-segmentation, but it’s probably better than most traditional datacenters which tend to focus on North-South traffic (web->app->DB) rather than East-West (app->app). The IaC nature of clouds allows for you to programmatically control both types of traffic!
With the right type of control plane I can see creating an app environment on-prem (with VMware) or in AWS or in Azure the same way and defining the ingress/egress controls to limit their exposure. Essentially you can treat the CSP as a separate availability zone, potentially with custom resources. This is what PaaS (eg CloudFoundry) promised.
So you breach into my b0rken Apache Struts app… you can’t get to Jenkins to infiltrate my CI/CD pipeline (hi, Solarwinds!) ‘cos you don’t have connectivity!
Of course you still need your traditional border controls, such as WAF, IDS/IPS, DLP between your cloud hosted environment and the internet.
A breach at the CSP level gets interesting, but the attacker then has different challenges. They might be able to jump into a VM by attacking the hypervisor, but then they still have the traffic restrictions. If they try to bypass the firewalls then they’ve got to somehow inject into the overlay network constructs… not practical!
Summary
Done correctly (ah, that’s the challenge!) a hybrid cloud need not be insecure. The risk is equivalent (if not less) than your traditional zoned datacenter. Especially if you are just single-cloud; again multi-cloud means you have to build these controls multiple times in different ways!
Of course I’ve just looked at this from an InfoSec perspective. There are other business reasons to look at multi-cloud.
What happens if your cloud providers decides to compete in your market space (Amazon are looking at providing financial services; Walmart won’t work with AWS)?
What happens if your cloud provider decides it’s not financial viable to provide a service due to losses?
What if your provider has a security issue and an attacker exploits it (fortunately didn’t happen here)?
From a security perspective, I wish I was single-cloud! Then I could focus on that. Multi-cloud makes everything much harder.
Hey, I said I had opinions!