The adoption of Amazon S3 or Simple Storage Service continues to grow unabated as a popular storage service. Organizations utilize Amazon S3 for nesting their assets, including anything that fit their business needs. Having said that, the Amazon S3 misconfigurations render the buckets prone to attacks such as content takeover or bucket takeover when they are not configured accurately.
Besides the fact that S3 buckets are visible, data stored in these get breached due to reasons other than misconfigurations, such as human errors. Most times, sensitive data in Amazon S3 are exposed. This could be unintentional, caused by errors of operators in storing sensitive information to public buckets or improper permission setups.
However, in other instances, there are misconfigurations of Amazon S3 that become likely targets for attackers through permeation, edits, and modifications of codes and spreading the same across the web.
What Are The Common Amazon S3 Misconfigurations?
Once a workload is breached, the compromise faced is lateral and continuous, allowing attackers to extract sensitive information. A hazardous way in which breaches leverage Amazon S3 Misconfigurations is by getting into IAM-privileged workloads, using the privileges for forming public buckets and moving data into them for external access.
The following are some of the most prevalent Amazon S3 misconfigurations observed across organizations.
It has been commonly observed that data requiring public access often resides in the S3 bucket classified as protected information. Such classification of data is prone to risks of breaches. Similar to workloads separation on servers, different S3 buckets must be employed for separation of data and workloads. A key dimension of classification that can be used is tags, which designates the S3 buckets comprising data as publicly accessible or sensitive. With such data classification, users are able to understand the way of using the S3 buckets, in turn ensuring data security and compliance.
For data in S3 buckets, there are three ways of encryption, namely, customer enabled encryption, KMS-enabled encryption, and S3-enabled encryption. The keys here are managed by the customer, Key Management Service, and Simple Storage Service respectively. For data protection from unauthorized users and cyberattacks, there are policies to ensure encryption of data uploaded in S3 buckets. This is critical while processing sensitive information.
Event Log Records
The records of event logs are not saved by default in S3 buckets. This implies that when buckets are made public, organizations will not be able to view and monitor access of files within the buckets by users. The event log records encompass requests, including the type of request, resources specified, and data & time when a particular request was processed. Misconfigurations made here can be incredibly harmful, resulting in unintended data access and compromisation of sensitive information.
Policies of S3 buckets set the permissions for data access, which are fragmented and powerful. Having said that, fragmentation leads to broadness in permissions for increasing the pace of initial deployments. This leads to an Amazon S3 misconfiguration as buckets are made publicly accessible due to haste. This leads to issues such as attackers having access to files in S3 buckets.
How To Prevent Breaches Entailed By Amazon S3 Misconfigurations?
For preventing data breaches due to Amazon S3 misconfigurations, organizations may follow approaches given below.
- Using robust policies and confining access to data in S3 buckets for safeguarding sensitive information from unauthorized access.
- Accurate identification and categorization of data hosted in Amazon S3 buckets as protected, confidential, or public. Also, organizations must make it a point to not blend protected or confidential information with publicly accessible information.
- Using the SSE or server-side encryption for data in S3 buckets and enabling Amazon to encrypt all data so that it allows decryption whenever the data is required.
- Enabling event log records at the file level while saving these logs to a root location allows organizations to carry out log analysis whenever there is a potential disaster or incident.
The Shared Responsibility Factor
Numerous security tools and controls are offered by cloud service providers (CSPs). Additionally, CSPs also hinge on the shared responsibility in case of security, which renders them responsible for the infrastructure and cloud security. However, the security of the environment is the responsibility of organizations themselves by using the tools and controls.
It has been observed that organizations often leave gaps in policies, thereby exposing their data to potential malicious attacks. It is necessary that organizations have adequate controls for monitoring, analyzing, and filtering the data traffic across workloads for a thorough security of their cloud environment.
To Sum Up
Organizations must decide on providing permissions to Amazon S3 resources by enabling certain actions they wish to allow for those resources. Providing permissions that are necessary for performing a particular task helps maintain a strong security environment. It is a radical requirement that organizations implement the least privilege access for ebbing security risks and impacts resulting from misconfigurations.