Secure and monitor your S3 buckets!

Security of S3 buckets is not a new topic but recently there have been a number of high profile data breaches resulting from improperly secured or maintained buckets.   For example the recent WWE breach where three million wrestling fans data was left in a publicly accessible bucket, you can read more about that here.  AWS works on a shared responsibility model and while they provide all the tools to securely store objects and monitor them its up to customers to use these features, manage their internal processes and track changes.

S3 buckets start life as private with only the resource owner having access to the resources, you then grant permissions based on your requirements.  It strikes me that most of these cases are unlikely to be intentional but instead down to poor internal policies, a lack of understanding of bucket permissions or of the objects that reside within a certain bucket.  Perhaps an object was stored in the wrong bucket or changes were made to a buckets access permissions allowing public access to objects that should be private.

This is where good planning, monitoring and change management comes into play.  I have a few suggestions below for managing S3 buckets.  There are also plenty of guides and third party tools available for configuring and auditing buckets.

Bucket Management

Some important bucket management considerations.

  • Its important to correctly plan and manage S3 permissions, as fixing issues later can be difficult and time consuming.
  • Create multiple buckets for your data.  Keeping sensitive data separate, especially if you have complex requirements, is much less prone to mistakes and errors than managing complex permissions on a single bucket.
  • Limit user permissions to what they need to access.  Its tempting to give all AWS console users “AdministratorAccess” don’t do this if its not needed.
  • Specify where users can save data.  Don’t let S3 become a dumping ground, its easy for things to get out of hand and lose track of whats where.
  • Enable bucket logging.
  • Watch out for the “Authenticated Users” group when configuring S3 ACL’s.  Its broader than many people realize.  Any authenticated AWS user from any account (not just yours) can access the resource.

Internal Processes and Change Management

There is a lot of focus on how easy things are in the cloud and its important not to forget that easy doesn’t mean less important or critical.  It’s easy to slip up and become complacent and when that happens where there is one issue there are usually more going unnoticed.  Make sure all you cloud inventory is correctly tagged and named so you know what it is for and how it relates to other services and keep up to date documentation on it.

Change management is also just as critical for your cloud deployments as it is for your on premise infrastructure.  Its important to plan and understand the affect changes will have on your infrastructure especially when those changes may now only be a few clicks in the console.

Bucket Policies

Bucket policies apply to a specific S3 bucket and can control permissions for the entire bucket and its objects.  The policy will specify which ‘principles’ (users) are allowed to access which resources. You can even use filters to restrict the types of file in a bucket. Even if you application checks file type and mine types of objects uploaded that doesn’t mean you shouldn’t implement additional layers of checks.

For example you can restrict what files are placed or accessed within the bucket to images only.  Its worth nothing that this only checks the extension of the file. Changing a files extension would by pass this.

"Resource": [
      "arn:aws:s3:::<yourbucket>/*.jpg",
      "arn:aws:s3:::<yourbucket>/*.png",
      "arn:aws:s3:::<yourbucket>/*.gif",
    ],

You can find more examples for bucket policies here.

User Policies

You can also use IAM user polices for controlling specific user access to a particular bucket or even sub folders within a bucket.  Don’t give users blanket access to S3, apply the required permissions directly to the user or to a specific group/role.  Be as granular as you need to be to cover all cases.

For example you may want a user to have access to the Finance folder within an S3 bucket.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:DeleteObject",
            "s3:DeleteObjectVersion"
         ],
         "Resource":"arn:aws:s3:::examplebucket/Finance/*"
      }
   ]
}

You can more examples of S3 user policies here.

Monitoring Bucket and Object ACL Changes.

CloudWatch actually allows you to track events associated with AWS resources; this includes S3 buckets and objects.  You can configure CloudWatch to monitor PutBucketACL and PutObjectACL events and perform an action such as sending an email via SNS when changes are made.

Screen Shot 2017-07-10 at 9.53.50 PM

S3 events support multiple targets including SNS notification, SQS message or AWS Lambda function.  These can be used to perform more complex checks on changes.

Monitoring types of objects placed into a bucket.

You may also want to keep an eye on the types of objects saved to a bucket.  For example if you have a public bucket which remains largely static, you could alert when any object is put into the bucket.

Screen Shot 2017-07-10 at 10.29.19 PM

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s