By default, resources in Object Storage Service (OSS), such as buckets and objects, are private to ensure data security. Only resource owners or authorized users can access them. To authorize third-party users to access your OSS resources, you can grant them specific permissions using various access control policies. For objects stored in a bucket, OSS provides the following permission and access control features:
Type | Description | Scenarios |
Resource Access Management (RAM) is an Alibaba Cloud service that you can use to manage access permissions for your resources. RAM policies are user-based authorization policies. You can use RAM policies to manage your users, such as employees, systems, or applications, and control their permissions to your resources. For example, you can configure a RAM policy that allows your users to only read from a specific bucket. | Grant OSS permissions to RAM users, user groups, or RAM roles within the current Alibaba Cloud account. | |
A bucket policy is a resource-based authorization policy. Unlike RAM policies, bucket policies can be easily configured in the console. A bucket owner can configure bucket policies for the bucket without requiring RAM permissions. You can configure bucket policies to grant permissions to RAM users from other Alibaba Cloud accounts or to anonymous users who access OSS from specified IP addresses. |
| |
You can configure the access control list (ACL) for a bucket when you create it, or you can modify the ACL of an existing bucket at any time. Only the bucket owner can perform this operation. The ACL of a bucket can be set to one of the following values: public-read-write, public-read, or private. | Set the same access permissions for all objects in a bucket. | |
In addition to bucket-level ACLs, OSS provides object-level ACLs. You can set the ACL for an object when you upload it, or you can modify the ACL of an existing object at any time. The ACL of an object can be set to one of the following values: default (inherited from the bucket), public-read-write, public-read, or private. | Set access permissions for a single object or multiple objects. For example, you may have a RAM policy or bucket policy that sets the access permissions for all objects in a bucket, or for objects with a specific name prefix, to private. If you want to make a specific object available to all anonymous users on the Internet, you can set the ACL of that object to public-read. | |
OSS lets you configure bucket policies and ACLs to grant public access. Public access means that OSS resources can be accessed without specific permissions or identity verification. However, public access can cause data breaches and generate significant outbound traffic over the Internet due to malicious access. To prevent the risks associated with public access, OSS provides the Block Public Access feature. After you enable this feature, existing public access permissions are ignored, and you cannot grant new public access permissions. This disables public access channels and ensures data security. |
| |
You can create multiple access points for a bucket and configure different access control permissions and network control policies for each access point. Using different access points for different business scenarios, you can simplify data access management for large-scale shared datasets. |
| |
Hotlink protection verifies source information, such as the Referer and User-Agent headers in HTTP requests, to prevent unauthorized websites from directly linking to and accessing your OSS resources. This prevents unauthorized bandwidth usage and resource hotlinking. You can configure hotlink protection using whitelists, blacklists, or regular expressions. | Allow only specified domain names or applications to access a bucket or object. This prevents resources, such as images and files, from being hotlinked by third-party websites. This feature is suitable for scenarios with high requirements for bandwidth and resource protection, such as audio and video playback, image display, and software downloads. | |
Cross-origin resource sharing (CORS) lets you configure cross-origin access rules for a bucket so that web page scripts can securely access OSS resources from different origins. You can configure parameters such as allowed origins, methods, and headers. | This is used when frontend pages, such as web applications, H5 pages, or miniapps, or third-party services need to make cross-origin requests from different origins to access OSS resources. Typical scenarios include direct frontend file uploads and cross-domain loading for web audio and video playback. |
If a bucket has multiple access control policies, such as RAM policies, ACLs, and bucket policies, see OSS Authorization Details for information about the detailed authentication process.