Object Storage Service:Reduce the risks of unexpectedly high fees caused by malicious access traffic

Unexpectedly high fees

When buckets are attacked or experience fraudulent traffic, the following financial consequences may occur:

• High bills: Additional OSS traffic bandwidth is consumed, and you are charged for the consumed bandwidth resources.

• Negative account balance: If you use OSS on a pay-as-you-go basis, due to factors such as the billing cycle and delayed bill processing, the service is not suspended immediately when your account balance reaches zero. This results in a negative account balance. If your buckets are attacked or experience fraudulent traffic, bandwidth or traffic spikes occur. You are charged fees whose total amount is higher than your Alibaba Cloud account balance.

Block Public Access

You can allow public access to OSS resources by configuring bucket policies and access control lists (ACLs). Public access allows access to OSS resources without specific permissions or authentication. Public access can cause data breaches and generate a large amount of outbound traffic over the Internet due to malicious access. To prevent risks caused by public access, OSS allows you to enable Block Public Access with a few steps for OSS, a bucket, an access point, and an Object FC Access Point. If you enable Block Public Access, existing public access permissions are ignored and you cannot configure public access permissions. This disables public data access channels and ensures data security. For more information, see Block Public Access.

Access OSS by using PrivateLink

PrivateLink is used to establish private, stable, and secure connections between virtual private clouds (VPCs) and OSS. PrivateLink prevents risks that may arise from accessing services over the Internet. This method not only improves data security, but also reduces the possibility of large financial losses due to fraudulent traffic. The following items describe the benefits of using PrivateLink:

• Isolation: You can use PrivateLink to access OSS resources from a VPC. This way, you can isolate OSS from the Internet. Your OSS resources can be accessed only from the VPC that you explicitly authorize. This prevents malicious access and attacks over the Internet.

• Permission control: You can use the PrivateLink endpoint in the VPC to manage access to OSS resources in a fine-grained manner. For example, you can restrict access from specific IP addresses or subnets, or specify specific security group rules to further enhance security.

• Traffic monitoring: If you deploy services in a VPC, you can better monitor and manage network traffic, detect and handle abnormal traffic at the earliest opportunity, and prevent risks caused by malicious access.

For more information, see Access OSS by using PrivateLink.

Set the ACL of your buckets or objects to private

Do not set the access control list (ACL) of your buckets or objects to public-read or public-read-write unless your business requires all users, including anonymous users, to read data from and write data to your OSS resources. For example, if you set the ACL of a bucket to public-read or public-read-write, the following changes take effect:

• Public-read-write: All users, including anonymous users, can read data from and write data to objects in the bucket.

  Warning

  This may result in unrestricted access to the data in your bucket and unexpectedly high fees. If a user uploads prohibited data to the bucket, your legitimate interests and rights may be infringed. We recommend that you do not set the bucket ACL to public-read-write unless necessary.

• Public-read: Only the bucket owner can write data to objects in the bucket. Other users, including anonymous users, can only read data from objects in the bucket.

  Warning

  This may result in unrestricted access to the data in your bucket and unexpectedly high fees. Exercise caution when you set the bucket ACL to public-read.

A bucket or object that allows public-read access or public-read-write access may lead to data breaches. Therefore, we recommend that you set the object ACL or bucket ACL to private. If you set the bucket ACL to private, only the bucket owner can read data from and write data to the objects in the bucket. Therefore, before you change the object ACL or bucket ACL to private, make sure that your business is not affected.

For more information, see Bucket ACLs and Configure ACL for objects.

Configure CloudMonitor alert rules

You can create alert rules to monitor the usage and the status of OSS resources. When an alert rule is triggered, CloudMonitor sends an alert notification to you so that you can check and handle the exceptions at the earliest opportunity.

For example, you can configure an alert rule for a bucket. If resource usage, such as inbound and outbound traffic over the Internet, inbound traffic from CDN, and outbound traffic to CDN, is equal to or greater than 100 MB during a specific cycle, such as one minute, the alert rule is triggered. In this case, CloudMonitor writes the alert information to the Logstore specified in Simple Log Service.

You can configure alert rules for a bucket or all OSS resources that belong to your Alibaba Cloud account. For more information, see Create an alert rule.

Configure hotlink protection

OSS allows you to configure a Referer-based filtering policy to block requests that contain specific Referers from accessing data in your bucket. This way, you can prevent unauthorized access and unexpected traffic fees.

When a browser sends a request to access an object in a bucket, the Referer header is included in the request to specify the source from which the request is sent. If hotlink protection is configured for the bucket, OSS compares the Referer in the request with the Referer configurations of the bucket.

• If the Referer in the request is included in the Referer blacklist or is not included in the Referer whitelist, the request is denied.

• If the Referer in the request is included in the Referer whitelist, the request is allowed.

For example, https://10.10.10.10 is included in the Referer whitelist of a bucket and the test.jpg image is stored in the bucket.

• User A links the test.jpg image to the https://10.10.10.10 website. When the image is requested from the website, the browser sends a request in which the value of the Referer header is https://10.10.10.10. OSS allows the request because the value of the Referer header in the request is included in the Referer whitelist.

• User B links the test.jpg image to the https://192.168.0.0 website. When the image is requested from the website, the browser sends a request in which the value of the Referer header is https://192.168.0.0. OSS denies the request because the value of the Referer header in the request is not included in the Referer whitelist.

For more information, see Hotlink protection.

Configure CORS rules

Cross-origin resource sharing (CORS) is a standard cross-origin solution that is provided by HTML5 to allow web application servers to control cross-origin access. This ensures the security of data transmission across origins. Browsers use the same-origin policy mechanism to isolate potentially malicious data and deny cross-origin requests by default. For example, if the JavaScript code on one website makes a request for a resource hosted on another website that has a different origin, the browser denies the request.

You can configure CORS rules to allow or reject cross-origin requests based on your requirements. For example, you can use the CORS configurations shown in the following figure to allow HTTP GET requests from www.aliyun.com to your bucket.

For more information, see Configure CORS.

Avoid naming objects by sequential prefix

When you upload a large number of objects and name them by using sequential prefixes such as timestamps and letters, dates, and numeric IDs that can be traversed, attackers can figure out the name rules and create a script to obtain all objects. This causes data leakage. In this case, we recommend that you add hexadecimal hash prefixes to your object names or name objects by reversing the order of timestamp digits. This can reduce the risk that the object names are traversed. For more information, see OSS performance and scalability best practices.