There are three types of S3 server side encryption:
- SSE-KMS
- SSE-S3
- SSE-C
Without having an AWS support person test each type and report back, one must assume that the only bulletproof s3 encryption methods are client-side (where you handle encryption and decryption yourself and they just store the blob) and SSE-C (where AWS don't store your keys, you send them in every bucket API request). But even that latter method has other caveats:
- What does the S3 service log? Who can access those logs?
- Where does TLS for your S3 https request get terminated? Who can view the traffic?
I'm assuming that this isn't just a regional issue, and that any AWS Support person globally could access buckets in any region. If so, then that's a big deal. If you're in Europe and your bank or healthcare provider is an AWS customer, how much trouble could you cause them (and by extension, AWS) right now?
Furthermore, with the antiwork movement and backlash amongst employees for their treatment of warehouse workers, one cannot guarantee that an AWS worker wouldn't do something to hurt the company.
Amazon need to head this of with a very thorough explanation of what happened and what was exposed directly and indirectly.
> SSE-C (where AWS don't store your keys, you send them in every bucket API request)
Since this is symmetrical encryption we're talking about, let's just be completely aware that the technical possibility to also store the encryption key definitely exists. It would violate the terms of service, of course.
For those who don't know how SSE-C works, it's that you send both the unencrypted data and a key in a request. AWS will encrypt the data with the key, and store it encrypted. To get your data back, you supply the same key in your subsequent request. AWS will decrypt the data using the key, and send the unencrypted data back to you.
During both those times when you gave AWS your key, you entirely trust that they will not also happen to store it for their own use.
> Without having an AWS support person test each type and report back, one must assume that the only bulletproof s3 encryption methods are client-side
It is normal practice to have a 3rd party access to your technical infrastructure (for example for purpose of support/maintenance). I was once contracted to maintain database for another company. You sign NDAs, you sign penalties, you sign your children to slavery and the right of first night with your wife. You know, standard business practice.
But if you care enough that you would not have contracted 3rd party access to the data, client-side is the only solution assuming the client is under your sole control.
- SSE-KMS
- SSE-S3
- SSE-C
Without having an AWS support person test each type and report back, one must assume that the only bulletproof s3 encryption methods are client-side (where you handle encryption and decryption yourself and they just store the blob) and SSE-C (where AWS don't store your keys, you send them in every bucket API request). But even that latter method has other caveats:
- What does the S3 service log? Who can access those logs?
- Where does TLS for your S3 https request get terminated? Who can view the traffic?
I'm assuming that this isn't just a regional issue, and that any AWS Support person globally could access buckets in any region. If so, then that's a big deal. If you're in Europe and your bank or healthcare provider is an AWS customer, how much trouble could you cause them (and by extension, AWS) right now?
Furthermore, with the antiwork movement and backlash amongst employees for their treatment of warehouse workers, one cannot guarantee that an AWS worker wouldn't do something to hurt the company.
Amazon need to head this of with a very thorough explanation of what happened and what was exposed directly and indirectly.