4 ms·

SSE-S3/SSE-KMS does provide defense against a few things: * Lost/stolen hard disks from AWS datacenter * Attacker or rogue AWS employee who has access to low

SSE-S3/SSE-KMS does provide defense against a few things: * Lost/stolen hard disks from AWS datacenter * Attacker or rogue AWS employee who has access to low level storage but not keys. The article is correct that this misses many important situations but it is still better than nothing.

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.
ejb999 4y ago
>>The article is correct that this misses many important situations but it is still better than nothing. I am not really sure its better than nothing - what it does do imo, is muddy the waters a bit for casual users, and perhaps make it seem like the customer doesn't really need to do as much securing themselves - because it is now 'encrypted by default' - giving a false sense of security - and as others have pointed out, really just protects against extremely rare edge case problems, i.e. the lost hard disk.
ilyt 4y ago
That's kinda like securing a door while not having walls
- tomschlick 4y ago
  Welcome to security certifications
colmmacc 4y ago
The biggest benefit is compliance. Many customers have to satisfy external regulators or internal compliance teams who mandate encryption at-rest. Those requirements are typically designed for relatively low-security on-premises data-centers and basic systems, rather than the kind of secure facilities and erasure coding schemes that AWS maintains, but always-on encryption makes the checkbox easy. Another often overlooked benefit of at-rest encryption is that it can enable crypto-shredding; delete the object key and the object can no longer be recovered. That's faster, more efficient, and better for the environment compared to other kinds of "secure erasure". Of course if you want robust crypto-shredding you do have to take some care about where the keys might be cached and for how long, but you can't do it without encryption at-rest.
- daitya 4y ago
  Author here. Agree, I cover these in the article. Crypto-shredding might be the AWS' motivation to enable the feature as a 0-click default. But for the customers, they don't get much beyond the compliance checkbox, and that too is questionable as more and more auditors become aware of cloud security controls.

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.

ejb999 4y ago

>>The article is correct that this misses many important situations but it is still better than nothing. I am not really sure its better than nothing - what it does do imo, is muddy the waters a bit for casual users, and perhaps make it seem like the customer doesn't really need to do as much securing themselves - because it is now 'encrypted by default' - giving a false sense of security - and as others have pointed out, really just protects against extremely rare edge case problems, i.e. the lost hard disk.

ilyt 4y ago

That's kinda like securing a door while not having walls

tomschlick 4y ago
Welcome to security certifications

colmmacc 4y ago

The biggest benefit is compliance. Many customers have to satisfy external regulators or internal compliance teams who mandate encryption at-rest. Those requirements are typically designed for relatively low-security on-premises data-centers and basic systems, rather than the kind of secure facilities and erasure coding schemes that AWS maintains, but always-on encryption makes the checkbox easy. Another often overlooked benefit of at-rest encryption is that it can enable crypto-shredding; delete the object key and the object can no longer be recovered. That's faster, more efficient, and better for the environment compared to other kinds of "secure erasure". Of course if you want robust crypto-shredding you do have to take some care about where the keys might be cached and for how long, but you can't do it without encryption at-rest.

daitya 4y ago
Author here. Agree, I cover these in the article. Crypto-shredding might be the AWS' motivation to enable the feature as a 0-click default. But for the customers, they don't get much beyond the compliance checkbox, and that too is questionable as more and more auditors become aware of cloud security controls.