I've read the article and the entire comment thread and nobody is talking about the cloud provider itself ... ?
When someone borgs[1] up their data to store at rsync.net we just assume that we are the threat. Of course I don't believe that but it's perfectly rational and we encourage people to think of rsync.net as a threat as they design their backups.
Comments in this thread are actually discounting the threat of Amazon personnel, GCS personnel, etc., as if that threat was zero.
Not only is it non-zero, I would go further: if you're storing the data on AWS and generating your keys on AWS and managing your keys with AWS ... you're doing it wrong.
This is an interesting and important point that you raised.
> if you're storing the data on AWS and generating your keys on AWS and managing your keys with AWS ... you're doing it wrong.
This is a reasonable thing to do if you've decided that you trust AWS and expect any violations of this trust to be dealt with by the legal department.
It's less reasonable if you're concerned about AWS employees going rogue and somehow breaking the security of KMS without anyone else knowing.
It's even less reasonable to do this if you're concerned about AWS credentials being leaked or compromised, which in turn grants an attacker access to KMS (i.e., a government would be more successful by compelling IAM to grant access than they would trying to subpoena KMS for raw keys).
(Sure, you can audit access via CloudTrail, but that's a forensics tool, not a prevention tool.)
But that's kind of the point I wrote in the article, no? You need to know your threat model. You've stated yours succinctly, and I think it's a commendable one, but many enterprises are a bit more relaxed.
> It's less reasonable if you're concerned about AWS employees going rogue and somehow breaking the security of KMS without anyone else knowing.
That's the least of the concerns. Remember AWS is subject to court orders of all types (legitimate ones and NSLs). Even if nobody goes rogue, any data that AWS (or any cloud/SaaS provide) could access, must be assumed to be compromised.
> Comments in this thread are actually discounting the threat of Amazon personnel, GCS personnel, etc., as if that threat was zero.
Thank you for this comment, this continuously blows my mind.
If one hands over cleartext data to some third party, one must assume they will abuse it. They might not, but "might" is not a convincing control in a threat model. If they can, one must assume they will. And plan accordingly.
Sure, sometimes it is ok. But any threat model that assumes a third party that could abuse the data but will never do so, is flawed.
It is vital to remember two things: Even if one 100% trusts the current management of a company to do No Evil, management can change. Second, regardless of managment, a company is subject to subpoenas and NSLs, so your data will be handed over.
If you don't directly control the generation, storage and usage of all encryption keys, your data is effectively in the clear.
Hey I do exactly this! Borg into rsync.i know it’s not exactly your domain, but are you guys working on making this flow easier? I found borg difficult to set up, and tbh I don’t really trust my setup long term. All the borg tutorials I found are on random people’s hobby blogs, it would be nice if you had one specific for rsync.net
Either way, Thank you for providing such an affordable service !
The volume/pricing entry point for borg is really inviting. I would love see the same things for the zfs part. Sadly 5Tb is a steep entry point for me.
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.
So many times people forget that encryption does not solve the confidentiality problems. It just translates it into key management problems. And this is such an amazing example I'd use in the future.
When someone borgs[1] up their data to store at rsync.net we just assume that we are the threat. Of course I don't believe that but it's perfectly rational and we encourage people to think of rsync.net as a threat as they design their backups.
Comments in this thread are actually discounting the threat of Amazon personnel, GCS personnel, etc., as if that threat was zero.
Not only is it non-zero, I would go further: if you're storing the data on AWS and generating your keys on AWS and managing your keys with AWS ... you're doing it wrong.
[1] https://www.borgbackup.org/