That's workable for many situations which only require data "storage", but the moment when you require cloud-side data "processing" too, the situation changes.
I would agree that if you have no use-case for cloud-side data processing, then the cloud doesn't need the encryption keys; however there are a lot of use-cases for data for which processing is highly advantageous.
For example, if you just want to store data in the cloud, sure, use client-side encryption. But what if you want to query it with, using an S3 example, S3 Select or Athena or load it into a data lake? There are a lot of things one might do. It's useful to be able to query data from within the cloud – without having to transfer it out and separately decrypt it.
This use-case is likely one of the primary reasons why customers are willing to trust cloud providers to manage the keys too – for many data sets, though not all. And that's what technologies like cloud KMS are good for. Access to the actual keys is tightly limited within the cloud provider, both among employees and technologically, and not even other cloud services are capable of accessing them (either accessing the keys or encrypting/decrypting using them) unless you grant them explicit permission, with internal technology that enforces this.
Maybe you didn't intend on using "new fancy foo service" to process your stored data yesterday, but today it sounds good, so you can alter an access control grant and allow it to interact with your existing stored data and the necessary encryption keys. Maybe every time some new data arrives in S3, you want to process that data with Lambda and synchronize it with another system. Then it's helpful if you can grant Lambda permissions to decrypt the data so that it can process it :-)
Generic server-side encryption does do something: it protects against threats that exist at the data center layer, such as certain attacks through lower layers of infrastructure that don't necessarily involve a full compromise of the machines involved, or inappropriate disposal of old storage devices, mistakes by employees, etc. It protects against some insider attacks, just not those by capable administrators.
> however there are a lot of use-cases for data for which processing is highly advantageous.
Most use-cases require 'processing', otherwise there would be no point of most cloud services and we would only ever use, say, S3.
The moment you spin up even a virtual machine, it will need to be able to decrypt the EBS volumes you have attached to it. Even if you encrypt the filesystem with your own mechanism and feed it the key by hand every time, it is still available in the instance. Instance memory is not easily available to AWS employees, but neither are the physical media that backs EBS volumes(whatever it is, details are scarce and all pieces may not even be physically in the same building). If we are concerned to that extent, then we can't use any other service. Which is ok, there are plenty of business that have requirements that disallow the use of any cloud providers.
KMS is a money printing racket for AWS. It only really helps you if someone walks out of a data center with your hard drive. For everything else the attackers are just going to get your IAM creds which have open access to all your keys.
I would agree that if you have no use-case for cloud-side data processing, then the cloud doesn't need the encryption keys; however there are a lot of use-cases for data for which processing is highly advantageous.
For example, if you just want to store data in the cloud, sure, use client-side encryption. But what if you want to query it with, using an S3 example, S3 Select or Athena or load it into a data lake? There are a lot of things one might do. It's useful to be able to query data from within the cloud – without having to transfer it out and separately decrypt it.
This use-case is likely one of the primary reasons why customers are willing to trust cloud providers to manage the keys too – for many data sets, though not all. And that's what technologies like cloud KMS are good for. Access to the actual keys is tightly limited within the cloud provider, both among employees and technologically, and not even other cloud services are capable of accessing them (either accessing the keys or encrypting/decrypting using them) unless you grant them explicit permission, with internal technology that enforces this.
Maybe you didn't intend on using "new fancy foo service" to process your stored data yesterday, but today it sounds good, so you can alter an access control grant and allow it to interact with your existing stored data and the necessary encryption keys. Maybe every time some new data arrives in S3, you want to process that data with Lambda and synchronize it with another system. Then it's helpful if you can grant Lambda permissions to decrypt the data so that it can process it :-)
Generic server-side encryption does do something: it protects against threats that exist at the data center layer, such as certain attacks through lower layers of infrastructure that don't necessarily involve a full compromise of the machines involved, or inappropriate disposal of old storage devices, mistakes by employees, etc. It protects against some insider attacks, just not those by capable administrators.