4 ms·

The author here is missing one big point: The people with physical access in AWS datacenters are not the same people who have access to the encryption keys. I

The author here is missing one big point: The people with physical access in AWS datacenters are not the same people who have access to the encryption keys. In fact, it's likely much more complex than that. The people with software access to the machines very likely don't have access to the key storing system (and definitely not the hardware). This means that the number of people it's possible to bribe to get access to your data is much smaller than if you can just bribe a DC employee to either smuggle the disk out, or make a copy onto a thumb drive. I'm not saying the number of people who could "break glass" and read anyone's data is zero. But it's at least an order of magnitude fewer than the hoards of people employed to swap hard broken drives all day every day. And the people with this "root" access will likely be very well paid, reducing (but not eliminating) risk of bribes.

dexterdog 4y ago
You think the datacenter hands at AWS are well-paid? I imagine that's a pretty junior position that is watched with hawk-eye security.
- Bedon292 4y ago
  Not the datacenter hands. They won't have access to the encryption keys. So the hard drive they do have access to won't be very useful.
- knorker 4y ago
  Like Bedon292 said, I think you misread my comment. I was saying thanks to encryption they don't have access. Most well paid engineers at AWS won't have access either. Presumably some minimal set would, but they would likely be pretty senior, and well paid. But ideally you'd want one set of people with access to the keys, another with access to the data, and a third with physical access, and no overlap. That way you need three people to conspire. But that's going to be very hard to achieve in practice. But it's not all or nothing. The closer you get to this goal the harder it'll be for someone to not just do it, but do it without triggering a tripwire from the security folks, or at least persist a log entry that if found would get them thrown in prison. Public cloud companies are not like a small startup where everyone has root. (sounds like twitter kinda was, according to recent reports)
eloff 4y ago
The author is not talking about getting someone with physical access. He’s talking about bribing someone with software access to your disks, who can access the data, regardless of the encryption settings.
- knorker 4y ago
  As I explained, and elaborated here (https://news.ycombinator.com/item?id=34017654 https://news.ycombinator.com/item?id=34017654) it's not as simple as that. But also. > The author is not talking about getting someone with physical access. Right. The author missed this as one of the major attack vectors that this aims to protect against. I don't think leaving out a real justification for it when saying it's snake oil speaks in favour of the author's point.
  - eloff 4y ago
    > Right. The author missed this as one of the major attack vectors that this aims to protect against. Did you read the article? He mentioned that right upfront.
    - knorker 4y ago
      First, here's a clip from the HN guidelines: > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" The article mentions it by dismissing it. No, really, this is the major attack vector this aims to protect against. That and the ability to two-key the system. No encryption, no two-key.
DrRobinson 4y ago
I think this is a valid point, though I don't expect the people in the datacenter to know which customer stores data on which disks. There could of course still be someone working there that steals data from all customers and you end up being part of that, but that's probably quite hard and risky for the employee since the datacenters are heavily monitored and access is restricted. As a targeted attack, I'd expect them to need to team up with a different department, which makes the attack even more expensive.
- knorker 4y ago
  Yup. Security is layers. Checking this box helps against some threats. Definitely not "close to useless". Public Cloud cloud have their shit together, but they also deal with millions of hard drives. I could definitely see a story coming out where someone finds a hard drive, some sensitive stuff on it, and just nobody has any idea how it got out. Stranger things than that happen every day. If it's encrypted then that's another layer of swiss cheese.
  - DrRobinson 4y ago
    > Definitely not "close to useless". It lowers the risk a minimum amount (which makes it not useless, but close to it.) Your resources are limited, so you want to prioritize actions that have good cost:benefit ratio. Re-encrypting disks is a significant effort (cost), effort that could be spent on something with better benefit. Should you spend a day encrypting a database or should you spend it on looking over publicly exposed S3 buckets? Ideally both, but resources are limited. Doing one action always means you're putting off something else.
    - knorker 4y ago
      This is a different argument. Did you see other comments in this thread, for example someone bought a drive online and turned out it still had some backblaze data? Compliance often has a bunch of useless checkboxing, but in that case it really mattered. I heard a rumor that some companies had their backups "in the other tower". People won't be making that mistake again. In some places they have a policy against two key people being on the same plane. It's ridiculous, until it isn't. Obviously there are priorities. But you can't say "I need to add features, not unit tests, because the company will go under without these features implemented very soon, and therefore unit tests are close to useless".

dexterdog 4y ago

You think the datacenter hands at AWS are well-paid? I imagine that's a pretty junior position that is watched with hawk-eye security.

Bedon292 4y ago
Not the datacenter hands. They won't have access to the encryption keys. So the hard drive they do have access to won't be very useful.
knorker 4y ago
Like Bedon292 said, I think you misread my comment. I was saying thanks to encryption they don't have access. Most well paid engineers at AWS won't have access either. Presumably some minimal set would, but they would likely be pretty senior, and well paid. But ideally you'd want one set of people with access to the keys, another with access to the data, and a third with physical access, and no overlap. That way you need three people to conspire. But that's going to be very hard to achieve in practice. But it's not all or nothing. The closer you get to this goal the harder it'll be for someone to not just do it, but do it without triggering a tripwire from the security folks, or at least persist a log entry that if found would get them thrown in prison. Public cloud companies are not like a small startup where everyone has root. (sounds like twitter kinda was, according to recent reports)

eloff 4y ago

The author is not talking about getting someone with physical access. He’s talking about bribing someone with software access to your disks, who can access the data, regardless of the encryption settings.

knorker 4y ago
As I explained, and elaborated here (https://news.ycombinator.com/item?id=34017654 https://news.ycombinator.com/item?id=34017654) it's not as simple as that. But also. > The author is not talking about getting someone with physical access. Right. The author missed this as one of the major attack vectors that this aims to protect against. I don't think leaving out a real justification for it when saying it's snake oil speaks in favour of the author's point.
- eloff 4y ago
  > Right. The author missed this as one of the major attack vectors that this aims to protect against. Did you read the article? He mentioned that right upfront.
  - knorker 4y ago
    First, here's a clip from the HN guidelines: > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" The article mentions it by dismissing it. No, really, this is the major attack vector this aims to protect against. That and the ability to two-key the system. No encryption, no two-key.

DrRobinson 4y ago

I think this is a valid point, though I don't expect the people in the datacenter to know which customer stores data on which disks. There could of course still be someone working there that steals data from all customers and you end up being part of that, but that's probably quite hard and risky for the employee since the datacenters are heavily monitored and access is restricted. As a targeted attack, I'd expect them to need to team up with a different department, which makes the attack even more expensive.

knorker 4y ago
Yup. Security is layers. Checking this box helps against some threats. Definitely not "close to useless". Public Cloud cloud have their shit together, but they also deal with millions of hard drives. I could definitely see a story coming out where someone finds a hard drive, some sensitive stuff on it, and just nobody has any idea how it got out. Stranger things than that happen every day. If it's encrypted then that's another layer of swiss cheese.
- DrRobinson 4y ago
  > Definitely not "close to useless". It lowers the risk a minimum amount (which makes it not useless, but close to it.) Your resources are limited, so you want to prioritize actions that have good cost:benefit ratio. Re-encrypting disks is a significant effort (cost), effort that could be spent on something with better benefit. Should you spend a day encrypting a database or should you spend it on looking over publicly exposed S3 buckets? Ideally both, but resources are limited. Doing one action always means you're putting off something else.
  - knorker 4y ago
    This is a different argument. Did you see other comments in this thread, for example someone bought a drive online and turned out it still had some backblaze data? Compliance often has a bunch of useless checkboxing, but in that case it really mattered. I heard a rumor that some companies had their backups "in the other tower". People won't be making that mistake again. In some places they have a policy against two key people being on the same plane. It's ridiculous, until it isn't. Obviously there are priorities. But you can't say "I need to add features, not unit tests, because the company will go under without these features implemented very soon, and therefore unit tests are close to useless".