Introduction to access control policies and their scenarios - Object Storage Service

By default, Object Storage Service (OSS) resources, such as buckets and objects, are private to ensure data security. Only the resource owner or authorized users can access them. To allow third-party users to access your OSS resources, you can use various access control policies to grant specific permissions. OSS provides the following features to manage permissions and control access to objects stored in buckets:

Type	Description	Scenarios
RAM Policy	Resource Access Management (RAM) is an Alibaba Cloud service for access control. A RAM policy is a user-based authorization policy. You can use RAM policies to centrally manage your users, such as employees, systems, or applications, and control their access permissions to your resources. For example, you can grant users read-only permissions for a specific bucket.	Granting OSS permissions to RAM users, user groups, or RAM roles under your account.
Bucket Policy	A bucket policy is a resource-based authorization policy. Compared to RAM policies, bucket policies are simpler to configure. You can configure them graphically in the console. Bucket owners can grant access permissions directly without requiring RAM operation permissions. Bucket policies support granting access permissions to RAM users from other accounts and to anonymous users with specific IP address restrictions.	Granting OSS permissions to RAM users or RAM roles under your account. Granting OSS permissions to RAM users or RAM roles under other accounts. Granting OSS permissions to anonymous users.
Bucket ACL	You can set an access control list (ACL) when you create a bucket or modify the ACL at any time after the bucket is created. Only the bucket owner can perform this operation. Bucket ACLs have three permission levels: public-read-write, public-read, and private.	Setting the same access permissions for all objects in a single bucket.
Object ACL	In addition to bucket-level ACLs, OSS also provides object-level ACLs. You can set an ACL when you upload an object or modify it at any time after the upload. Object ACLs have four permission levels: default (inherits from the bucket), public-read-write, public-read, and private.	Setting access permissions for one or more individual objects. For example, a RAM policy or bucket policy might set all objects in a bucket, or objects with a specific prefix, to private. To make a specific object accessible to all anonymous users on the Internet, you can use an object ACL and set its permission to public-read.
Block Public Access	OSS supports public access through bucket policies and ACLs. Public access means anyone can access OSS resources without specific permissions or identity verification. Public access increases the risk of data breaches and high outbound traffic costs due to malicious access. To avoid these risks, OSS provides the Block Public Access feature. When Block Public Access is enabled, existing public access permissions are ignored, and new public access permissions cannot be created. This prevents public access to your data and ensures data security.	Enabling Block Public Access at the global OSS level. Enabling Block Public Access at the individual bucket level. Enabling Block Public Access at the individual access point level. Enabling Block Public Access at the individual object FC access point level.
Access Point	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 simplifies access management for large, shared datasets.	A customer manages dozens of app clients. Each client requires different access permissions to data in different folders within the same bucket. A customer stores all of their company's data in a single bucket. Dozens or even hundreds of internal teams must be restricted to accessing only specific folders or files.
Hotlink protection	Hotlink protection validates the source of HTTP requests, such as the Referer and User-Agent headers. This prevents unauthorized websites from directly linking to your OSS resources, which helps prevent bandwidth theft and resource hotlinking. You can configure hotlink protection using whitelists, blacklists, or regular expressions.	Preventing third-party websites from hotlinking resources, such as images and files, by allowing only specified domain names or applications to access a bucket or object. This feature is ideal for scenarios that require strong protection for bandwidth and resources, such as audio and video playback, image hosting, and software downloads.
Cross-domain settings	Cross-origin resource sharing (CORS) lets you configure rules for a bucket to allow web page scripts to securely access OSS resources from different origins. You can configure parameters such as allowed origins, methods, and headers.	Allowing frontend pages, such as web applications, H5 pages, and miniapps, or third-party services to make cross-origin requests to access OSS resources. Typical scenarios include direct file uploads from the frontend and cross-domain loading for web-based audio and video playback.

If a bucket has multiple access control policies, such as RAM policies, ACLs, and bucket policies, see Details of OSS authorization for information about the authorization flow.