[L0g4n]

Such concerns specifically led to my decision of only uploading sensitive data to S3 with client side encryption. Since the aws cli tool only supports server side encryption with keys stored on amazon servers (where the non-default managed keys cost like 1 USD per month), I decided to simply symmetrically encrypt the backup of my syncthing data volume with AES256 using gnupg and only then pushing it to the S3 bucket.

[geek_at]

this should be the default user behaviour for any cloud storage. Don't put unencrypted (company) data on a cloud infrastructure you don't have full control over.

Also reminds me of the (hyped?) "outrage" when a former facebook developer stated that they used to have a "default password" that allowed fb devs to log into every account and the media were like "omg they could have logged in and seen your photos". I mean... yeah they're the developers they could always do that even without the password

[krisoft]

> yeah they're the developers they could always do that even without the password

Not really. Obviously facebook the company can always access your data. Weather or not an individual developer can do the same, which developers can do it, how they can do it, and under what level of supervision this would be is a design choice.

It is possible to design a system with very high level of security and ones with none too. As with any design considerations it has trade-offs. A super secure system might introduce dev and operational frictions which the company might deem unnacceptable. But even with that consideration the question is a lot more complicated than a simple “yeah they’re the developers”.

[oneplane]

Sadly, "yeah, they are the developers" applies far more often than any other scenario.

Unless a business is heavily regulated and checked for compliance, the burden and friction introduced by developer access controls to the data of the software they write is anecdotally not seen as a positive investment in any company I've seen the internals of.

[zelon88]

Just assume every engineer has access to everything. From a client perspective that's how you have to treat it.

There are so many zero days in regular consumer software, just imagine how many are in closed source public facing Amazon services.

Now multiply that by 100 to get the number of zero days that probably exist in Amazon's closed source dev only back end environment.

[krisoft]

> Just assume every engineer has access to everything.

Wise rule to live by. I would certainly advise everyone to assume that.

On the other hand geek_at was talking about a slightly different thing. They were talking about how the media criticised FB for having too lax controls on private information. geek_at even called it an "outrage".

We can and should absolutely ask platforms to do better while at the same time playing it safe ourselves with the data we control. There is no contradiction there.

There is an other layer in which it feels we are talking by each other. You mention zero days, and yes those are a thing and yes an insider is in an excellent position to find them and exploit them. Finding them and patching them is a good idea for sure. (For many reasons.) But the FB thing mentioned wasn't about an exploited zero day. It was a company sanctified system and associated work practices. We can demand that a company develop better practices (where not every engineer needs this high of a level of access to do their job) without expecting them to find and patch every single vulnerability.

[withinboredom]

Not at amazon, but I've def written internal-only-and-never-used-outside-of-team-type-tools that has obvious security issues, just to let non-devs get things done.

[geek_at]

> Weather or not an individual developer can do the same

This was early-early facebook. Like under 10 developers back in the day. But obviously today a facebook frontend developer should not and probably has no access to the database

[brodouevencode]

It should be the default behavior in places where it makes sense - customer PII data, financials, etc. I'm not going through the headache of implementing encryption for otherwise public images.

Maybe AWS should have another object storage product that's specific to sensitive material. I know that would flip Corey Quinn's lid because it would be yet another AWS product (h/t to him for actually have a valuable twitter post and not just snark) but I honestly don't care - I'd rather have extra level of confidence. For this there would be absolutely no data access.

Tangentially, I wonder if this role has been deployed to GovCloud?

[joombaga]

Last I checked it had not been deployed to GovCloud.

[unethical_ban]

What does "full control in the cloud" mean to you? It sounds like that's an oxymoron in your opinion, but correct me if I'm wrong.

I get the idea, but also realize this is fundamentally incompatible with using the range of services at AWS. Fringe-future tech aside, you need unencrypted data to process it and use it. AWS isn't just S3, it's lambda, it's hosting and data science and databases.

Having just read the tweet, as weird as it is to give AWS the benefit of the doubt, I agree with others in that thread. If you KMS encrypt your data, then the engineers will likely only have the ability to see encrypted data. My guess is that there are processes and monitoring in place to ensure this is only used as a break-glass.

Have you ever dealt with automation of AWS resources? There are definitely issues where, by putting incorrect permissions on a KMS key or an S3 bucket, not even root can get your data back. This is likely what this is for. Customers would rather have a non-removable AWS break-glass than their own root account.

[geek_at]

With full control I mean things like having access logs for everything that goes in and out the box (like when you selfhost a minio instance)

[aynsof]

When the Australian Cyber Security Centre did their security assessment of AWS, they actually recommended that Australian government agencies not do this. Their recommendation was for agencies to use KMS. They considered that if agencies managed encryption keys themselves, the risk of them misplacing their keys and losing access to their data was too high.

[chakerb]

Cloudstore[1] can do something similar automatically.

[1] https://github.com/infor-cloud/cloud-store

[L0g4n]

Just skimmed it, looks useful, with mentioning keypair I'm assuming they use RSA keys or something similar. Why the choice for asymmetric encryption?

[guitarbill]

The code says it uses the public key for uploading/encryption, and the private key for downloading/decryption. It's useful to be able to split writing and reading with cryptographic guarantees, for security or organisational purposes. E.g. if a client only has the public key and should it be compromised, it can't read the data. Or it allows you to have less strict access controls on uploading clients.

[the_arun]

I wish AWS official clients did this automaically by default. Customers could opt out from encryption if it is public data. When an aws account is created it also creates a default CMk (specific to that aws account) for entire service which customers could change if they want.

[brundolf]

Is there a managed service that does this? A Dropbox-like UX that client-side encrypts everything and then persists it on S3 or the like. I don’t want to fiddle with it myself but I’d pay for that kind of service

[purplesnowflake]

https://www.skiff.org/

[thebean11]

rclone can do it on the fly (no need to store the encrypted version on upload or download) which simplifies the process

[xvector]

Yeah, if you aren't using E2EE cloud storage you're doing it wrong.