I seem to be spending a lot of time discussing the Cloud Service Provider’s (CSP) side of shared responsibility, and no where near enough time discussing our side of shared responsibility. Time to throw down more thoughts on why you need to worry less about AWS, Azure and GCP’s engineering, and spend more time focused on your own security hygiene.
Don’t lose sight of the fact that "95 percent of cloud security failures will be the customer’s fault."
Let’s discuss four threat models.
The Grand Bezos Conspiracy
This one took off a few years ago. Amazon competes with us. If we put our data in AWS, then Amazon will have our precious trade secrets.
The idea AWS is going to give Amazon our data is pretty dumb. AWS makes the bulk of the profit for Amazon, and destroying that trust between customer and provider would hurt Amazon way more than the value your worthless trade secrets will bring. Besides Amazon could probably just buy them from the Chinese.
This threat vector isn’t a concern when you’re on-prem. You’re not going to steal your own stuff.
Foreign Subversion
That sounds a lot more dramatic than Chinese student goes to work for Google and steals your data.
While I’m highly dismissive of the Bezos Conspiracy, this is a real threat. Amazon, Apple, Google and Microsoft hire thousands of foreigners. It’s unlikely that a background check will turn up the fact they work for a foreign government when said background is provided by said foreign government.
This threat vector is also a concern with self-hosted infrastructure. But you can (within anti-discrimination law at least) choose not to hire foreign workers, and the ones you do hire can be monitored and you can decide what data they have access to. With the scale and advanced nature of the big three cloud providers, they have to hire the best and the best doesn’t always come with a US Passport.
Internal Subversion
It is well documented that employees of cloud providers can be hacked.
It is also well documented that some employees have extraordinary access to customer data and customer accounts.
Put together, a reasonably valid threat model is a spear-phish attack against an employee of your CSP. One that you’re just as susceptible to when you host your own infrastructure. But on-prem you have the illusion of more control and detectability.
The United States Government
Speaking non-partisan: The US Government, for (at least) the past four administrations, feels it is above the US Constitution when pesky things like the fourth-amendment stand in the way of their law enforcement objectives (war-on-drugs, war-on-crime, war-on-terror, war-on-leaks, etc).
You have to assume that a secret court can issue a secret order requiring your CSP to keep secret the order for your data. Even if they are willing to stand up to the government, their ability to defend your fourth-amendment rights is limited.
The fundamental difference in this threat vector is that you will know when a government goon busts down your door with a secret court order. Something you will not know about if the order is against your CSP.
The threat here is not just the US Government (even though all three major CSPs are US corporations). They all have datacenters in foreign jurisdictions and they all have major business dealings in foreign countries.
Mitigations for these threat models
Fundamentally, if you’re paranoid enough to think that Jeff Bezos, Satya Nadella, or Larry & Sergey are going to enlist dozens of their employees to siphon off your data to use against you, then you just need to stay on-prem.
That said, not doing business with a CSP owned by a competitor because you’re in retail, software, or advertising isn’t a completely unreasonable stance. But plenty of market leaders are perfectly happy to use the best CSP regardless of how other business units of that provider might compete against them.
If you’re worried about subversion, either malicious foreign subversion or the inadvertent variety that hit Twitter this year - then you need to ask some tough questions of your CSP:
- What technical controls exist to prevent employees from accessing your data?
- What levels of management approval are required before an employee can access your data?
- What separation of duties exists between the team that manages the data and the team that manages the encryption & key-management of your data?
GCP has taken a very open and product-orientated approach to this with Access Transparency and Access Approval.
Given the nature of cloud encryption, I do not see any mitigation strategy for a [National Security Letter] or similar court order from a foreign government against your CSP for your data (short of client-side encryption and on-prem key management). In the most extreme circumstances, and CSP will be able to reset your admin credentials and provide those to US or foreign law enforcement. All the technical controls and encryption is irrelevant if the Law Enforcement agent can impersonate you to the cloud provider.
Your best bet is to work with providers that are 1) not beholden to the US government for contracts, 2) have made at least some public stance against warrantless wiretaps and data requests and 3) don’t give government agencies secret rooms in their data centers to make it easier for the government to shuffle through everyone’s data.