What is The Cloud? (it's Zero Trust)

Is this guy really going to do a “What is the cloud?” article in 2020? Yes, he is. I mean, I am. Because I want to talk about the cloud. No, not cloud computing. No, not a series of tubes. Not “just someone else’s computer”. This cloud:

This actual cloud. We’ve all seen it thousands of times, and you’ve probably used it a lot if you’re reading this article. You might have seen it in use like:

Or:

But have you ever stopped to think about what it means? It’s not “The Internet”. Nor is it simply abstracting away complexity to simplify the diagram. What it actually means is:

You simply don’t care what happens here. One end of the connection talks to the other end and what happens in between is of no concern. Generally, we’re caring a lot about our “private”, “internal” networks - and you can see that in the usual array of private IPv4 space, subnets, VPCs, VLANs, VPNs, leased lines, DirectConnects, ExpressRoutes and proxies that get built in to a typical application. We’re not caring at all about the bits where we’ve stuck a cloud on it. These are usually the most sensible parts, and not caring at all is an incredibly powerful tool.

THE POWER OF NOT CARING

By now you’ve probably realised that this is a thinly-veiled article about Zero Trust. Which was invented by the market research firm, Forrester in 2010.

OF COURSE IT WASN’T INVENTED BY FORRESTER IN 2010, here from RFC 3552 in 2003:

The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when one of the end-systems has been compromised is extraordinarily difficult. It is, however, possible to design protocols which minimize the extent of the damage done under these circumstances.

By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate.

That was summing up the approach taken to securing communications on the internet since the 1990s. It was never the case that security on the internet has depended on trusted networks. Not until everyone and their dog started building bad web applications from the dotcom boom onward.

We’ve had the ability to secure communications over an untrusted network for quite some time with cryptography (barring a few hiccups as Moore’s law inexorably marched on). I would always bet my company’s future on the defensibility of mathematical proofs over the defensibility of my global IPv4 network comprising windows desktops, on-premise servers and frequently-hacked, broadly-deployed commercial routers. But having seen the rise in anti-intellectual, anti-science postings on LinkedIn this year I can see why some people might prefer wishing really hard and checking their horoscopes every morning to see if it’s a bad security day.

There’s no such thing as an internal network. If you have an internal network with office PCs on it that can receive email and view websites, you don’t have an internal network. Your all-server, datacentre internal network is one domain controller exploit, or yet another Cisco RCE exploit away from being a public network for someone. Your carefully crafted cloud network of private subnets, internet gateways and VPC endpoints is one terraform apply away from being wide open to the world, if it’s not already and you haven’t noticed yet.

So it generally is, and always was, a good practice to never invest any trust in the network that your service is sitting on. This means abandoning a couple of misguided principles that you may not even be aware you were resting on:

• An IP address is not an identity
• Being able to route to a service does not authorise you to access it

These are obvious lunacy on an untrusted network, but can creep insidiously into thinking and system design when there’s a presumption that services are running on a private network.

You already have zero-trust endpoints, they’re your customer-facing websites! They don’t care where their traffic originates from (mainly) and they use strong identity and authorisation to securely serve requests. With good monitoring and other operational practices befitting an internet service. Why would you have that and then screw things up on your backend services with 1970s network thinking? It’s even easier to secure communications there, you have total control over both ends of the connection and you can be a lot less permissive in what you accept over the wire than a generic web server. Your strong identity can be a cryptographically strong identity with a client certificate.

Here’s an illustration of a client-authenticated TLS handshake (credit to Cloudflare, I didn’t want to draw it myself)

Let me summarise that for you when someone without a client certificate tries to access your service:

1. Hi!
2. Hello. Give me your client certificate.
3. Er…
4. [FATAL handshake_failure, socket closed]

That’s a very small attack surface. The whole process got nowhere near your application code. It’s possible there’s a remotely exploitable vulnerability in the TLS implementation but these things get a lot of thought and review. Your entire public cloud deployment is accessible via AWS’s, Azure’s or GCP’s management API and they’re hanging out on the internet using only API keys for identity.

On a trusted network your point of failure is the network. If that’s compromised then all bets are off. And in a cloud deployment who can make network changes? Pretty much anyone! In a zero trust network your point of failure is your certificate signing authority. And who can make changes to that? With a little effort around security controls, pretty much no one. Now, you could expend great effort in preventing anyone from making network changes to your secure cloud network topology, removing capabilities from delivery teams until they can’t get anything done themselves and have to raise tickets to get reserved CIDR blocks and update VPC peering just for their service to simply talk to a service built by another team, slowing down delivery to an absolute crawl. You could just shrug your shoulders when a team that’s built their services on Azure asks how they connect to a service another team has built on AWS. Or you can party like it’s 1995 when even SSL v2 had client certificates and secure your network communications properly. Oh look, Adam references IPv6 in his 1995 overview of SSL! We were so hopeful back then…

Yes, there are rare cases where you have to run your network communications across private links.

• For performance reliability - see jgc’s postmortem of the recent cloudflare outage. Do cloudflare need private links to secure communications between two points? Heck no, they do that over the internet as their business. The private links are for performance guarantees (Although they did the opposite of guarantee performance here, thanks to a configuration update)
• For cost reasons - you probably aren’t shifting enough terabytes to worry about internet backbone transit costs, but you might be!
• For contractual or otherwise legal requirements - these have always been rare and are becoming rarer

Secure, broadly-available, internet-facing service endpoints are more secure than “internal” services that trust “private” networks. They’re hugely more flexible and adaptive to a changing world and better for your business. They enable resilient, multi-cloud systems. They force good operational practices because no one is lulled into a false sense of security. If someone asks you to do it a different way say, “No, I’m not putting these services on a trusted network accessed over a private link it’s not safe.”

Send them this article if you like. Here’s a reference secure network architecture to get them started: