0

We have applied the guardrails mentioned in this posting, AWS Preventive S3 Guardrails. 1. Unfortunately, we are not getting the anticipated outcome. We applied the Disallow Changes to Encryption Configuration for Amazon S3 Buckets 2.

The SCP has a DENY for s3:PutEncryptionConfiguration, with a condition excepting the arn:aws:iam::*:role/AWSControlTowerExecution role.

The issue is that anyone can create an S3 bucket, which is acceptable. However, when creating the bucket either in the console or via CloudFormation and attempting to specify encryption either SSE or KMS an error is generated and the bucket created without encryption.

Ideally we need to have anyone be able to create an S3 bucket and enable encryption. What we were hoping that this SCP would do would be to prevent removing encryption once applied to the bucket.

We are anticiapting similar issues with the other guardrails mentioned in the article:

Disallow Changes to Encryption Configuration for all Amazon S3 Buckets [Previously: Enable Encryption at Rest for Log Archive] Disallow Changes to Logging Configuration for all Amazon S3 Buckets [Previously: Enable Access Logging for Log Archive] Disallow Changes to Bucket Policy for all Amazon S3 Buckets [Previously: Disallow Policy Changes to Log Archive] Disallow Changes to Lifecycle Configuration for all Amazon S3 Buckets [Previously: Set a Retention Policy for Log Archive]

Has anyone encountered this issue? What would be the best way to implement allowing the buckets be created with the needed encryption, logging, bucket policy and lifecycle and once created disallowing removal or changes after the bucket was created?

Jay Bonk
  • 37
  • 4

1 Answers1

0

I'm afraid scp's dont offer the flexibility you need, simply because the condition keys you need are not present in the api calls. There is not a policy that says "allow createbucket with the condition that it has encryption enabled".

I've worked in various platform teams for corporates to implement these types of controls and have encountered these limitations many times. Basically there are three strategies:

  1. Detective compliance
  2. Corrective compliance
  3. Preventive compliance

First make sure you have visibility over how stuff is configured. You can use aws config rules for this. There are definitely rules out there that check s3 buckets for encryption settings. Make sure to centralize the results of these rules using a aws config aggregator in your security account. After detection you can manually follow up on detected misconfigurations (or automate this when running at scale).

If you also like to correct mistakes you can use aws config auto remediation actions. Also various open source tools are available to help you with this. An often used one is cloud custodian with the c7n-org plugin. Also many commercial offerimgs exist but are quite expensive.

With scp's or iam policies you can prevent someone from doing stuff which is a bit lower risk than correcting misconfigurations after they happened. However, it's also very inflexible, policies can get complex real quickly and it also it doesnt tell the user why he cant do something. Often, scp's are only used for the very simple tasks (e.g. no iam users may be created) or blocking actions outside or certain regions.

I'd opt for making sure you detect stuff properly first, then see if you can either correct or prevent it.

Edit: If you have mature teams that only use ci/cd and infra as code you can also make sure your security controls are implemented using tools like cfn-guard in a pipeline build stage. Simply fail the build if their templates are not up to standards.

Edit2: to get back on your question: for some actions it's possible to prevent using scp's if there is a separate api for disabling stuff like a 'DisableEncryption' action. However for most actions it's a PutEncryptionSetting-like action and you cant really tell if its being enabled or disabled.

LRutten
  • 1,634
  • 7
  • 17