This blog post describes how to create customer access policies to Amazon S3. These buckets are by default not public, and this blog takes it further by locking the bucket to Amazon Connect where your Amazon Connect reports and call recordings are stored. By using appropriate permissions assigned to your Amazon Connect account, you can view scheduled and saved reports, and playback call recordings from the Amazon Connect interface. Security and data privacy is a top priority for many customers, so it’s important to comply with any organization or privacy requirements. To do so, you can use IAM policies to add an additional layer of security for Amazon Connect artifacts stored in Amazon S3. This helps to avoid a data leak or breach that could compromise customer information. This adds additional security to maintain your customers’ privacy and may help you comply with local regulations.

Warning

Be careful when changing security settings. These changes are permanent and you could restrict your own access. I recommend doing this on a test bucket first. If you make a mistake, you may lose all access to the resource you are trying to manage. This could adversely affect how your Amazon Connect instance functions. Consider restricting access in a test S3 bucket before doing so in your production environment.

The following steps discussed in this post are required to restrict access to your S3 bucket

• Identify the S3 bucket being used for your instance
• Identify the IAM role being used for Amazon Connect
• Use the command line to identify the role ID
• Create the S3 bucket policy
• Confirm access to the S3 bucket

So, let’s begin.

Identify the S3 bucket

Determine which bucket is associated with your Amazon Connect instance. If you didn’t choose to use an existing S3 bucket when you created your instance, a new bucket was created for you. You can find which bucket is being used for Amazon Connect in the Amazon Connect dashboard, as shown in the following example:

The name of the bucket being used for my instance example is: connect-25fd0a3be3ef

Identify the IAM role

Identify the IAM role being used by the Amazon Connect service. This allows you to perform actions in the Amazon Connect instance.

Note: Amazon Connect recently introduced Service-linked roles. The steps in this article apply to Amazon Connect instances created prior to the release of service-linked roles on 10/17/2018. We’ll update this article with information for service-linked roles in the near future.

To find the Amazon Connect service IAM role

1. Find the role created when you created your Amazon Connect instance.
   If you created multiple instances, you can determine which role is associated with each instance by matching the creation time. If the column is not displayed, you can add it by choosing the cog icon in the top-right corner of the page.

If you can’t determine which role goes with which instance, there is a way to determine the correct one. Match the S3 bucket used for an instance with the bucket the role has permission to access.

To confirm that you are using the correct role

1. Choose the role that you want to verify.
2. Expand the policy by choosing the arrow next to it as shown in the following example.

The S3 bucket to which the role has permissions is displayed in the Resources section of the policy.

For example, in my instance, the S3 bucket is named connect-25fd0a3be3ef. This matches the bucket name listed in the instance settings we looked at earlier, so we know that it is the correct role.

On the same page, we now get the Amazon Resource Name (ARN) for the role we are working with. You can find the ARN for the role in the Summary section for the page, as shown in the following example:

Note

When getting the ARN, make sure that you do not lock yourself out of the S3 bucket. Use the Copy to clipboard icon to copy the ARN for the role to use in the next steps. Consider pasting the ARN into a document or other location so you can access it without reopening the IAM console.

The ARN for the role used for my instance is

connect-access-role-e3529bf0-6678-4ec4-8f66-a0fdd58cbcd9 

Identify the role ID

Use the AWS Command Line Interface (AWS CLI) to find the ID for the role, for which the S3 bucket will be locked.

To find the role ID

1. Open the AWS CLI.
2. At the prompt, type the following command:
   aws iam get-role –role-name connect-access-role-e3529bf0-6678-4ec4-8f66-a0fdd58cbcd9
3. Copy the value of the RoleId, as shown in the following example:

Warning

When you assign a RoleId to an S3 bucket, only that role has access to the S3 bucket and its contents. This user can view and modify items in the bucket, and view policies for the bucket. I suggest using an Admin user account that also has access to the AWS Management Console.

In the next step, I locate the RoleId of the Admin role used to manage all of my AWS services.

To find the roleID for the Amazon Connect service role

1. Open the AWS CLI.
2. At the prompt, type the following command

   aws iam get-role --role-name Admin

3. Copy the RoleId for the Admin role, and paste it into a text document or other location to use later.

I’ll use this role ID and the role ID for the Amazon Connect service account we copied previously to create a policy for the S3 bucket.

Create the S3 bucket policy

Create a policy to assign to the S3 bucket, as shown in the following example:

{
  "Version": "2012-10-17",
  "Statement": [{
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::connect-25fd0a3be3ef",
        "arn:aws:s3:::connect-25fd0a3be3ef/*"
      ],
      "Condition": {
         "StringNotLike":{
           "aws:userId":[
             "AROAJJ4OT5B3EVMNARNW6:*",
             "AROAINV7BYMRZP3NV66DI:*"
      ]}}
  }]
}

This policy denies access to any S3 action and denies access to the specific S3 bucket, including everything in it. The Effect: Deny statement indicates that the policy is used to deny access to an action or resource. The StringNotLike condition instructs the policy to deny access to all accounts that are not included in the policy under aws:userId.

In the previous example, you see that the ARN for the S3 bucket to assign permissions for is listed under Resource. It is: arn:aws:s3:::connect-25fd0a3be3ef

The second item listed in the Resource section is the ARN to the S3 bucket again, but with /* after it. This assigns the policy to include all subfolders and objects in the S3 bucket. Copy this policy, and replace the values for the S3 bucket ARN and the user IDs to the values for your S3 bucket and roles.

To assign the Bucket Policy

1. Choose the name of the bucket to apply the policy to.
2. Choose the Permissions tab, and then choose Bucket Policy.
3. Paste the policy with your updated values into the policy editor. Be sure to include the opening and closing bracket in the policy
4. Choose Save.

After you save the policy, only the Admin role and the Amazon Connect service roles have access to the bucket and all files in it. If you or anyone else attempts to access the bucket using another account, an Access Denied error message appears.

You can still access the bucket using the AWS account root admin. However, only users with sufficient permissions are able to access call recordings from within Amazon Connect.

Confirm access to the S3 Bucket

To confirm that you can access the bucket from Amazon Connect, search for a contact and attempt to listen to a recording associated with the contact. This assumes that you have enabled call recording in a contact flow. You can search for a contact using Contact search as shown in the following example:

Attempt to play a recording associated with a contact, as shown in the following image.

If you have permission to play the call recording, it opens and plays, as shown in the following example:

You have now secured your S3 bucket.

Summary

In this post, we demonstrated how you can apply IAM policies to Amazon S3 buckets so that only users and service roles with appropriate permissions are allowed to access the buckets. Anonymous users (with public-read/public-read-write permissions), authenticated users and service roles without the appropriate permissions are prevented from accessing the buckets.