Example Scenarios for AWS Config Continuous Monitoring of Amazon S3 Bucket Access Controls

Recently, AWS Config announced two new managed rules to detect Amazon S3 buckets that have overly permissive controls. You can now check your S3 buckets continuously for unrestricted public write access or unrestricted public read access. In addition, you can view compliance of all your S3 buckets against these rules, and receive notifications via Amazon SNS when permissions change. You can also view the permissions history in the Config console.

With these new rules, you can view the historical state of bucket Access Control Lists (ACLs) and bucket policies, and you can identify when changes were made. If someone changes a bucket policy or a bucket ACL, the Config rule automatically re-evaluates the new effective access. The rules evaluate the ACL to determine whether any anonymous user or any AWS user is allowed read or write permissions. The bucket polices are evaluated using a semantic-based automated reasoning engine, which returns a compliance decision.

“These AWS Config rules are backed by a new formal model of IAM semantics, offering a dramatic improvement over existing tools that rely on simple pattern matching, which often fails to capture the nuances of the IAM policy language,” said Bridgewater Associates engineer Dan Peebles. “For the first time, we can make strong universal statements about our S3 IAM policies and be confident that our assumptions aren’t violated. We’ve been keenly collaborating with AWS on this formal model during its development; it provides the foundation for future tools that will be game changers in our ability to reason about our AWS infrastructure.”

Tracking configuration changes to S3 bucket ACLs and policies is valuable from a governance perspective. It tells you how and when a bucket permission was modified. You can use this information to troubleshoot operational issues and outages, and maintain audit compliance. In addition, by turning on CloudTrail Data Events for S3 buckets, you can receive full audit logs around who read or wrote objects to that S3 bucket.

Learn more: Logging Data Events with the CloudTrail Console

In this post, we present an example scenario in detail.

Use case: S3 Public Write Access Rule

Granting all AWS users access to write to your S3 bucket is almost never an intended configuration. Ensuring that S3 bucket policies don’t provide unrestricted write access is a security best practice within AWS Security. Misconfigurations of the bucket policy that provide unrestricted write access can allow unauthorized users to add malicious content to a bucket and overwrite content.

One scenario where you should be sure these rules are in place is after the acquisition of a new company. Often a large enterprise centrally manages a number of AWS accounts, ensuring consistent centralized controls are in place. When a new business unit joins the organization, with their own AWS assets, it can be difficult for a security team to quickly assess the security posture of the acquired business.

As an engineer tasked with assessing the security posture of newly acquired accounts, you can turn on write access detection to quickly see the status across all buckets in a given account. First, log in to the Config console. Choose Add rule to see the list of rules. Type ‘write’ in the search bar to see the s3-bucket-public-write-prohibited rule. The following screenshot shows the Add rule page.

Click the rule description, which opens the rule configuration page. The default values are set to trigger rule evaluation on any change to S3 resources. Click Save and the rule will be enabled for your account, with the status shown as Evaluating…

In this scenario, rule evaluation is completed and returns a status of Noncompliant. The evaluation identifies one bucket belonging to the newly acquired business that has a resource policy granting public write access.

The Annotation field provides information about which access control is Noncompliant: the bucket ACL, the bucket policy, or both. In the example that follows, the Annotation field notes that it is the bucket policy that violates the check.

The Config rule marks the bucket resource as Noncompliant if either the bucket ACL or the bucket resource policy allow unrestricted public write access. If the bucket ACL and bucket policy are configured with different write accesses, this means that the controls are in conflict. Providing users visibility into these conflicts allows them to correct the conflict.

In our scenario, the startup you have recently acquired attempted to apply a policy to restrict bucket access to their AWS users logged on using multi-factor authentication (MFA). This is the policy that was used:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:PutObject*",
      "Resource": "arn:aws:s3:::config-write-test/*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Here the condition key aws:MultiFactorAuthPresent isn’t sufficient to restrict public write access. Since the Principal value is set to “*” the net effect of this policy is to restrict S3 write access to any AWS user in any account who is logged on with multi-factor authentication. Since anyone could create an AWS account, and enable login using MFA, this policy effectively grants public write permissions. There is no clause tying the principal to the account where the bucket is hosted. The ability to reason in this way about this net effect of a policy can be quite difficult to do using simple scripts or using human inspection, but it is now possible using the semantic-based automated reasoning tool for policies developed by AWS.

An example of an appropriately configured S3 resource policy that only allows access from a given VPC is shown in the following example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Open access to vpc-01234567",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::config-write-test/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:sourceVpc": "vpc-01234567"
        }
      }
    },
    {
      "Sid": "Deny access to non vpc-012345667",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "*",
      "Resource": [
        "arn:aws:s3:::config-write-test/*"
      ],
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:sourceVpc": "vpc-01234567"
        }
      }
    }
  ]
}

The semantic-based automated reasoning tool for policies used by the Config rule correctly determines that the policy correctly limits writes to those coming from the selected VPC. By limiting write access to a given VPC, we can now re-evaluate the rule, and we are now Compliant.

Enabling these rules in every account owned by a newly acquired company lets the central IT team within an organization quickly identify any misconfigurations that could pose a potential risk to the organization. If there are multiple accounts, the new StackSet feature can be used to enable the Config rule across multiple accounts. The rule quickly pinpoints the source of the misconfiguration, enabling quick remediation to bring the account in line with best practices.

Checking unrestricted public read access

You can also check for unrestricted public read access, using a similar new rule. For media or website content, granting public access to read your S3 bucket is the desired configuration. However, if that isn’t your use case, unrestricted read access is likely a misconfiguration. Enabling the s3-bucket-public-read-prohibited rule ensures that you are alerted to any misconfigured buckets that allow public read access today. After any misconfigurations are fixed, the Config rule will continuously re-evaluate any changes made in the future to ensure continued compliance.

To enable the rule, follow the steps outlined earlier for the public write rule, instead using ‘read’ as the rule search term. After rule evaluation is enabled and completed, the console will report a Compliant status if no S3 buckets allow unrestricted public write access. If any buckets do allow unrestricted public read access, the status will be reported as Noncompliant, along with the number of Noncompliant buckets. The annotation provided explains which access control is Noncompliant, either the bucket ACL, the bucket resource policy, or both.

Summary

By enabling these new rules, you can now easily monitor S3 access controls and ensure that access to your data is configured as you expect. These rules can be accessed using the AWS Management Console, as shown here, or evaluated using the AWS CLI or AWS SDKs.