4 ms·

These are far less likely outcomes than your root account being compromised, an IAM fuck up, dumb assume role configuration or something using an assumed IAM ro

by wrldos 4y ago

These are far less likely outcomes than your root account being compromised, an IAM fuck up, dumb assume role configuration or something using an assumed IAM role being compromised and having verbatim access to the bucket. The feature is there for paperwork reasons.

TavsiE9s 4y ago
It's there so folks can check their list and go "Yep, it's encrypted at rest. Yay us!"
- thallium205 4y ago
  SOC2 here we come!
- daitya 4y ago
  Author here. Exactly, that's the biggest risk!
oxfordmale 4y ago
If your root account is comprised, it is game over anyway.
maximilianroos 4y ago
"less likely" risks are still worth protecting against! I still put my seat-belt on, even though there's an airbag in the car.
klodolph 4y ago
Less likely? Yes. However, these are real, legitimate risks that need to be mitigated! This is not just some faff that needs to get put on paper. Think about your risk model: there are a lot of employees at your cloud provider, and a lot of high-profile customers. There's a defense in depth approach here. Metal detectors, security guards, and searches to enter & exit data centers. Data encrypted when on-disk. Keep the keys in some KMS system. Physically isolate the KMS system, use HSMs, restrict permissions to the KMS. Without these measures, you might end up with a system where ordinary customer support representatives, software engineers, data center technicians, or system administrators / SREs can exfiltrate customer data on a whim. At a large cloud provider like Amazon, Google, or Microsoft, that's not a small attack surface. That's a lot of people. The idea is to make it extremely hard for one of these employees to exfiltrate customer data without somehow leaving a record of it which ultimately gets the employee fired and prosecuted. Customers will make mistakes too--screw up their permissions, fail to encrypt their data, or whatever. The idea behind defense in depth is that any one security measure can probably be circumvented, but multiple independent security measures are harder to circumvent. It's really easy to be cynical about security but I have worked at cloud providers and the threats are real.
- wrldos 4y ago
  I'm fully aware of those risks. The issue for me is a matter of realism. A combination of the default policy being poor on all AWS services, the shared responsibility model of AWS delegating this risk to clients and the default security posture in the industry being terrible makes the real problem of solving this like traipsing across a field covered in poo. An analogy; you have to tick the box to put your front door key under the doormat. The burglar knows where the hole in your fence is and knows you might keep your keys under the door mat. Plus your kids left their keys on the github bus. Of course the SOC2 audit says you ticked the box and you tell everyone your house is a castle.

by wrldos 4y ago

TavsiE9s 4y ago

It's there so folks can check their list and go "Yep, it's encrypted at rest. Yay us!"

thallium205 4y ago
SOC2 here we come!
daitya 4y ago
Author here. Exactly, that's the biggest risk!

oxfordmale 4y ago

If your root account is comprised, it is game over anyway.

maximilianroos 4y ago

"less likely" risks are still worth protecting against! I still put my seat-belt on, even though there's an airbag in the car.

klodolph 4y ago

Less likely? Yes. However, these are real, legitimate risks that need to be mitigated! This is not just some faff that needs to get put on paper. Think about your risk model: there are a lot of employees at your cloud provider, and a lot of high-profile customers. There's a defense in depth approach here. Metal detectors, security guards, and searches to enter & exit data centers. Data encrypted when on-disk. Keep the keys in some KMS system. Physically isolate the KMS system, use HSMs, restrict permissions to the KMS. Without these measures, you might end up with a system where ordinary customer support representatives, software engineers, data center technicians, or system administrators / SREs can exfiltrate customer data on a whim. At a large cloud provider like Amazon, Google, or Microsoft, that's not a small attack surface. That's a lot of people. The idea is to make it extremely hard for one of these employees to exfiltrate customer data without somehow leaving a record of it which ultimately gets the employee fired and prosecuted. Customers will make mistakes too--screw up their permissions, fail to encrypt their data, or whatever. The idea behind defense in depth is that any one security measure can probably be circumvented, but multiple independent security measures are harder to circumvent. It's really easy to be cynical about security but I have worked at cloud providers and the threats are real.

wrldos 4y ago
I'm fully aware of those risks. The issue for me is a matter of realism. A combination of the default policy being poor on all AWS services, the shared responsibility model of AWS delegating this risk to clients and the default security posture in the industry being terrible makes the real problem of solving this like traipsing across a field covered in poo. An analogy; you have to tick the box to put your front door key under the doormat. The burglar knows where the hole in your fence is and knows you might keep your keys under the door mat. Plus your kids left their keys on the github bus. Of course the SOC2 audit says you ticked the box and you tell everyone your house is a castle.