Allow restricting the use of SSE-C encryption

[ab77]

See, https://aws.amazon.com/blogs/security/preventing-unintended-encryption-of-amazon-s3-objects/

(Override all values in parentheses)

(Run yamllint folder/template.yaml, cfn-lint -i E1019 E3002 E2520 -t folder/template.yaml, and aws cloudformation validate-template --template-body file://folder/template.yaml before you open a PR)

(Do not include multiple changes in one PR. Open additional PRs instead.)

---

Allow blocking the use of SSE-C encryption as per AWS security blog to prevent unintended encryption of Amazon S3 objects (ransom attacks).

The linter suggestion can be sorted in a separate PR:

$ cfn-lint -i E1019 E3002 E2520 -t  state/s3.yaml
W3045 Consider using AWS::S3::BucketPolicy instead of AccessControl
state/s3.yaml:176:7

[michaelwittig]

Thanks @ab77 I wonder if we could go one step further and always block this.
We configure the bucket's default encryption to either use SSE-S3 or SSE-KMS. @andreaswittig what do you think?
If we don't go for a deny by default I would recommend to rename the parameter RestrictCustomerKeys to e.g. BlockSSEC or at least RestrictCustomerProvidedKeys to not confuse users with KMS customer managed keys.

[ab77]

Thanks @ab77 I wonder if we could go one step further and always block this. We configure the bucket's default encryption to either use SSE-S3 or SSE-KMS. @andreaswittig what do you think? If we don't go for a deny by default I would recommend to rename the parameter RestrictCustomerKeys to e.g. BlockSSEC or at least RestrictCustomerProvidedKeys to not confuse users with KMS customer managed keys.

I am OK with either approach, we currently don't have a use-case for enabling SSE-C.