> * KMS Encrypted objects would not be accessible because the support personnel would need permission policies that grant `kms:decrypot` permissions to encrypted objects.
This is only true if you are using SSE-KMS *and* are creating/managing the CMKs used to encrypt objects. If you’re using SSE-S3 or SSE-KMS with the default AWS S3 key (aws/s3) there is no key policy to manage.
Of course SSE-C or 100% customer-managed crypto would be immune as well, but under different mechanics.
> Objects with a default-deny bucket policy could not have been circumvented with the support team's escalated privilege.
I would wager this is done for a vanishingly small percentage of buckets used in production. Less than one percent for sure.
The general point you’re making seems to be that if you had a comprehensive, defense-in-depth security strategy for your cloud computing environment then this would have had no effect, and i do agree with that. I just think that in reality this would have provided access to wide swaths of customer data.
This is only true if you are using SSE-KMS *and* are creating/managing the CMKs used to encrypt objects. If you’re using SSE-S3 or SSE-KMS with the default AWS S3 key (aws/s3) there is no key policy to manage.
Of course SSE-C or 100% customer-managed crypto would be immune as well, but under different mechanics.
> Objects with a default-deny bucket policy could not have been circumvented with the support team's escalated privilege.
I would wager this is done for a vanishingly small percentage of buckets used in production. Less than one percent for sure.
The general point you’re making seems to be that if you had a comprehensive, defense-in-depth security strategy for your cloud computing environment then this would have had no effect, and i do agree with that. I just think that in reality this would have provided access to wide swaths of customer data.