When Forrester’s John Kindervag first wrote about the concept of the Zero Trust Model (ZTM) it almost seemed too paranoid. ZTM posits that attackers are so successful in penetrating networks that a network architect should consider each and every device—from the Internet, to the firewall, to the switch, to the server—to be potentially compromised. Therefore nodes in the network should not implicitly trust each other: all connections should be encrypted, and only the endpoints should trust each other (after authentication).
ZTM seemed paranoid at the time because that’s not how traditional network architecture worked at all; architects established a security perimeter so that nodes on the safe side of that perimeter could freely communicate.
Enter the Australians
For the last five years, no region has embraced cloud more fully than the Australians. The financial services industry is usually the last to the cloud party in most regions, but not in Australia. Down under, the financial services industry has been leading the way with cloud-first policies. Now the Australians are aggressively pursuing the multi-cloud strategy, as well.
Multi-cloud uses multiple public clouds; AWS, Google, and Azure are the three largest. It has advantages over a simple cloud-first policy, but security isn’t one of them. Australian network architects are struggling to secure the multi-cloud and thus, without realizing it, they are building the ultimate use case for ZTM.
There are two drivers for multi-cloud: utility cost is the first. Different cloud providers have different costs, and these can vary day to day or even hour to hour. An agile architecture can take advantage of these price differences by shifting compute and storage loads to the current cheapest compute and storage providers.
The second driver for multi-cloud is to avoid the single point of failure. Cloud failures happen; just because cloud is “someone else’s computer” doesn’t mean that it is somehow magically immune to operational error. Azure suffered a global failure when one of its SSL certificates expired unnoticed. Customers using only Azure during the outage would have been high and dry. But those with a multi-cloud strategy, in theory, would see their business processes increase in the other two public clouds to compensate.
Aussies make it more complicated
Those ambitious Australians are trying to take multi-cloud one step further by mixing application components across cloud providers. Imagine building an application with three components; a web front end, a payment system, and a database. Now imagine the three components can move between public clouds independent of each other. On Monday, the web front end resides on AWS, the payment system on Google, and the database on Azure. On Tuesday, Google has a sale, so they all move there. On Wednesday, AWS has cheaper storage but more expensive compute, so the payment system moves back to Google and the database stays at AWS.
Nifty. Who doesn’t like that idea? Organizations have been using similar cost savings strategies with bandwidth providers for 20 years.
But how do you secure the application components when they’re shifting from cloud to cloud? Any traffic traversing from one public cloud to another is by definition crossing the Internet and should therefore not be trusted. Each component of the application must treat each of the others as untrusted; this is the definition of ZTM.
Can multi-cloud be secured without tripling latency?
If the web front end and the payment system were always in the same cloud, they could rely on the cloud’s security perimeter to talk to each other in the same security zone. But when they aren’t in the same cloud, they’d better be using encryption to keep their transactions from being exposed—and therefore potentially compromised—across the Internet. Normally, one would use TLS encryption to do that.
But you can’t architect a solution where each transaction creates two additional TLS connections that hop between the public clouds. The additional latency would kill the user experience of the application. The best you could hope for would be to create TLS tunnels between the components and then multiplex individual transactions through the tunnels.
Ideally, the public clouds would have interfaces that make it easy to migrate load and then establish TLS tunnels. But they don’t. And if you were a public cloud, why would you make it easy for customers to skip out on you when your costs go up? And what are the odds that the interfaces for transitioning into and out of each cloud would be the same? Unlikely, at best.
When a gap appears within interfaces or services, products and companies spring up to fill the gap. For multi-cloud, the nascent Cloud Access Security Broker (CASB) startups are supposed to help with these significant challenges. But it is early days, and customers are saying that even with CASBs, gaps still exist.
Charting the way forward?
You have to give props to these brave Australian souls experimenting with multi-cloud. If all goes well, these explorers will chart the way forward to securing the ultimate zero-trust environment, creating opportunities and solutions for the rest of us. Or, they may prove just the opposite; here there be monsters, and it’s not worth the time and resources to build a strategy that reaches across multiple clouds.
Related Reading: Steps to Implementing a Zero Trust Network
Related Reading: Security, Compliance Remain Biggest Concerns Over Cloud