Protect your data on Amazon S3: Security permissions and best practices

Amazon’s Simple Storage Service — Amazon S3 — is one of the most widely used and secure web-hosting services in the world, but mismanagement of its permissions settings by users can cause significant data leaks.

Companies can mitigate the risk by establishing processes to regularly check their Amazon S3 permissions settings as well as their vendors’ settings. This is also true for companies that don’t use Amazon S3 — because their vendors could, and likely do, use the service.

Security concerns

The ubiquity of Amazon S3 is difficult to exaggerate. Worldwide, the web-hosting service is used by more than 200,000 unique domains, according to data tracked by SimilarTech. It hosts over 1.6 times more data than its major competitors, Microsoft, Google, and Alibaba — combined.

Such market dominance means that when an Amazon S3 registered user’s permissions are set to anything other than private, stakes are high. A simple permissions misconfiguration can result in anyone with internet access being able to search through a user’s files, access them, and make changes.

In July 2017, for example, one of Verizon’s third-party vendors inadvertently made a security setting public on an Amazon S3 storage server. This single-click oversight resulted in more than six million of Verizon’s customers having their personal data leaked online, including names, phone numbers, and PIN codes.

If either Verizon or the vendor had proactively managed their permissions settings using the security tools provided by Amazon Web Services (AWS), the data leak likely could have been avoided.

Managing permissions

Everything hosted on Amazon S3 is categorized into three types of resources:

• Buckets. The highest level of organization, buckets hold every file — or object — on the server.
• Objects. Individual files stored on the server.
• Subresources. Files that are attached to and dependent on other files are known as subresources. For example, a website configuration.

Amazon S3 provides access policy options to specific buckets and objects. By default, all buckets are set to private. This means only the Amazon Web Services (AWS) account that created the bucket can access it and the objects within it until access permissions are granted to other AWS users or the public.

Because of the private default setting, there are only two ways companies can potentially compromise their data:

• Granting access permissions during web development, and then neglecting to switch those permissions back to private
• Granting full control access permissions that allow third-parties to give their own access permissions to resources

To help ensure these misconfigurations don’t happen, it’s prudent for companies to understand their level of data exposure and why it exists — internally and through third-party vendors.

This can be accomplished by regularly and systematically answering three questions:

• Do only the personnel who need to make global changes to company permissions settings have access?
• Do third-party vendors have the least possible access to sensitive company data?
• Are third-party vendors managing any data in addition to accessing it, and do they need to?

With this knowledge, companies can more easily and proactively assess and manage their Amazon S3 resources and risk exposure.

Permissions settings

When granting permissions, AWS users decide who can have access to their buckets and objects and the specific actions they’re allowed to take.

There are four built-in groups users can grant permissions to:

• Everyone. Anyone with an internet connection.
• Authenticated Users. Anyone with an AWS account.
• Log Delivery. This group grants access to a bucket only when the bucket is used to store server access logs.
• Private. Only the AWS root account.

Each of these groups as well as specific AWS users can be granted three types of access for each permissions setting:

• Read access. This allows designated users to access files but not alter them.
• Write access. This gives designated users the ability to read, create, delete, and overwrite files.
• Full control. This provides designated users with the ability to do everything a write access permission allows. It also allows designated users to grant permissions for the resource to others.

These security settings are managed through the permissions tab on the Amazon S3 user interface using bucket permissions and access control lists (ACLs) or through a tool called identity access management (IAM).

Bucket permissions

Amazon S3 users can restrict bucket and object access by specific user, networks, or even by specific hours of the day or certain applications. Bucket owners can also create other resources within a given bucket and grant separate permissions to those resources for different users using ACLs.

ACLs

By making use of ACLs, users can place separate permissions around specific objects within buckets that may have different overarching permissions settings. This provides an additional level of security to the files within a bucket if the bucket’s permissions settings are too broad for some of the specific files within it.

IAM

Account holders can use Amazon’s IAM tool to create additional accounts and groups of accounts, and then give those groups their own permissions policies. This allows one account to read files that need access to multiple accounts simultaneously.

IAM is helpful for developers, larger organizations, and account auditors because it enables users to display a complete list of the permissions they’ve granted through a single graphical display, rather than having to go through each individual bucket and file separately to check its permissions settings.

Best practices

Many companies give full permissions during the web development process — usually to a test account — then plan to change permissions before launch, but never do. From a leadership perspective, it’s prudent for development teams to be aware of the risks associated with this approach and to proactively work toward avoiding them. If the permissions aren’t corrected, data can be instantaneously and irrevocably leaked.

Companies can mitigate this risk by limiting the number of users who have access to private files from the start of the development process by assigning conservative bucket policies and ACLs as well as using IAM to ensure only the users who need access to certain files have it.

Monthly reviews of permissions, including third-party vendor’s permissions, can help companies ensure these settings don’t change.