Hacker News Reader

Comment by tobyhede | Hacker News Reader

At least in AWS, practice is to encrypt all connections between components, and to have granular least privilege permissions at every point. Behind the scenes AWS follows the same principles for the infrastructure. I would argue a lot of cloud set-ups are inherently more secure than the equivalent on-prem of large enterprises.

View on HN

Encryption only helps if you can guarantee that your attacker can't get access to the layer below where the runtime decrypts things.

A cloud hack like the parent poster talks about assumes that you get access to the hypervisor layer and can look at the RAM of the guest machines.

This is not inconceivable. Rather, it seems quite reasonable given the complexity of hypervisors and the prevalence of CPU architecture bugs that makes these attacks easier.

can look at the RAM of the guest machines

This is what https://en.wikichip.org/wiki/x86/sme is for

If you have hypervisor access you can simply ask the guest to read the memory for you.

It was only a year ago since the most recent, one of several, leaks associated with AWS/S3. Have people forgotten?

IF you're referring to the Capital One incident, that had nothing to do with AWS. Their systems behaved as intended. It was a error in the implementation of Capital One's systems.

OP suggests cloud setups with AWS are inherently secure due to practice, but many past breaches demonstrate otherwise.

Your misinterpretation of their comment is the source of your confusion: note that they said “a lot” and “more secure”, not perfect. There are many more breaches of on-premise systems but we don’t say that those are too risky to use — it all comes down to cost. One big advantage that cloud environments have is that you can assume everything is API-driven and there are off the shelf tools to look for common problems like the Capitol One WAF setup. You certainly can do that on-premise but you have more work to do and the bespoke nature of the environment makes misunderstandings easier.

Having trouble finding a reference since the search terms aren't too friendly (lots of targeted ads though), was there one where it wasn't an account configuration issue?

I'm aware of several leaks that were basically "account holder left bucket wide open"

Some of that is on AWS for initially making the defaults too open, but at the end of the day, S3 was doing what it was told.

Is there some case where S3 was locked down, and the data still leaked?

Yes, that is what leakage is. Even the SolarWinds breach was likely made possible due to a cloud leak. Not a strong argument for cloud setups.

> Even the SolarWinds breach was likely made possible due to a cloud leak

What? Their internal build system was comprised and the password for the FTP that hosted their software updates was "solarwinds123"

This had nothing to do with the cloud/a issue with a cloud provider.

> password for the FTP that hosted their software updates was "solarwinds123"

Secrets in a public github repository is a leak, in the cloud.

> Secrets in a public github repository is a leak, in the cloud.

Someone uploading their secrets to GitHub has nothing to do with the cloud and everything to do with the incompetence of the people using it.

"This is the clouds fault because one of our engineers made a mistake and 'the cloud' didn't stop them!" does not really hold up.

Reply on news.ycombinator.com