Securely Managing Entitlement of S3 Resources

Here we’ll talk about securely managing entitlements of S3 resources including managing access control to S3 objects and utilizing audit logging to keep track of the usage of shared resources.

Amazon’s AWS services allow for accounts to grant access to resources from other accounts on AWS. This creates opportunities for organizations to share resources with partners, or to offer access to resources that they control either through the Amazon Marketplace for SaaS apps or manually.

This type of multi-tenant resource usage is easily accomplished by utilizing IAM roles on the involved accounts. IAM roles allow organizations to create fine-grained policies that can govern how different users can access and use resources hosted on their services. IAM roles created by a host account can be assumed by partner accounts by linking the roles across the accounts. The policies allow the host to have complete control over how partners or paired accounts can access and utilize the shared resources.

S3 resources also allow for explicit access control definitions.

How To Manage External Roles

Note: we’re using Amazon’s concept of an “external_id” that must match across accounts. This is not required and there are other methods, but it is a great and straightforward extra security feature to keep access even more controlled.

Create the policy file in the following format (with the permissions as you would like to allow):

external-assume-role.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow external id account to assume role",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"
      },

    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "EXTERNAL_ID"
      }
    }
  }
  ]
}

entitlement-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
  {
    "Sid": "Allow changing password for a shared role",
    "Effect": "Allow",
    "Action": ["iam:ChangePassword"],
    "Resource": "*"
  },
  {
    "Sid": "Allow listing of all buckets",
    "Effect": "Allow",
    "Action": "s3:ListAllMyBuckets",
    "Resource": "*"
  },
  {
    "Sid": "Allow list and get commands on a shared bucket and its contents",
    "Effect": "Allow",
    "Action": [
      "s3:List*",
      "s3:Get*"
    ],
    "Resource": [
      "arn:aws:s3:::",
      "arn:aws:s3:::/*"
    ]
  }
  ]
}

For more information on types of permissions available, visit the AWS policy summary page.

Next create the role for the tenant and attach the policy created in the previous step:

aws iam create-role --role-name <role-name> --assume-role-policy-document file://external-assume-role.json
aws iam create-policy --policy-name <policy-name> --policy-document file://entitlement-policy.json
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/<policy-name> --role-name <role-name>

On the tenant side, a cross account role must be added to their aws config file using the ARN for the created role on the host account:

[profile <profile-name>]
role_arn = arn:aws:iam::<host-acct-num>:role/<role-name>
source_profile = <source-profile-name>
external_id = <external-id>

S3 Access Control

Note: this guide assumes you already have created an S3 bucket that you wish to share access to. For instructions on how to create an S3 bucket, see the AWS S3 Documentation.

Buckets and objects can also have permissions set up attached to them directly, rather than relying on policies to govern their general access. Access can be added for individual users or groups by providing either an email, display name, ID, type, or uri location.

aws s3api put-bucket-acl --bucket <bucket-name> --grant-full-control emailaddress=<email-1>,emailaddress=<email-2> --grant-read uri=<uri-to-group>

For more information on further options, visit the AWS docs on the put-bucket-acl command.

Setting up Audit Logging

Once the roles and access controls have been set up on the resources you wish to share, audit logging can be a useful way to keep track of the usage. These logs provide information about what api calls have been called on what objects, by who, and when the calls took place.

First, create the Cloudwatch log group that will be used to monitor the activity:

aws logs create-log-group --log-group-name <log-group-name>

Create a role and policy for the cloudwatch logs to be written with:

cloudtrail-role.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow cloudtrail to assume a role",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
    "Action": "sts:AssumeRole"0
    }
  ]
}

cloudtrail-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow create log stream",
      "Effect": "Allow",
      "Action": [
      "logs:CreateLogStream"
    ],
  "Resource": [
    ""
  ]
  },
  { 
    "Sid": "Allow adding log events to bucket",
    "Effect": "Allow",
    "Action": [
      "logs:PutLogEvents"
    ],
    "Resource": [
      ""
    ]
  }
  ]
}
aws iam create-role --role-name <role-name> --assume-role-policy-document file://cloudtrail-role.json
aws iam create-policy --policy-name <policy-name> --policy-document file://cloudtrail-policy.json
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/<policy-name> --role-name <role-name>

Then, using the ARN given in the output of the above command, create a trail and link it to the S3 bucket or object you want to monitor:

aws cloudtrail create-subscription --name <trail-name> --s3-new-bucket <log-bucket>
aws cloudtrail update-trail --name <trail-name> --s3-bucket-name <log-bucket> --s3-key-prefix <bucket-to-trail> --cloud-watch-logs-log-group-arn <log-group-arn> --cloud-watch-logs-role-arn <arn-from-output-of-policy>

Audit Log Usage

In the case of S3 shared resources, you can enable a Cloudtrail and Cloudwatch stream that will allow the system to gather information about API usage on all items within the bucket.

This can allow hosts to keep track of the usage of their shared resources and can shed light on how the policies they are managing for partners could improve, or allow the detection of warning signs or red flags in how their partners are utilizing their resources.

After the auditing logs have been put into Cloudwatch, they can be monitored and analyzed by security analysts, or hooked into security software like Imperva Sonar. From there an organization can set up alerts or have detailed reports delivered on the usage of their shared resources, and give insights to allow a more secure and beneficial relationship with their shared partners or tenants.