Introduction to access control policies and their scenarios-Object Storage Service(OSS)-阿里云帮助中心

Object Storage Service (OSS) resources such as buckets and objects are private by default, and you control access to them by using access control lists (ACLs), authorization policies, and security protection features. This topic describes how OSS evaluates an access request and how to select a permission control mechanism.

Quick selection

Select a permission control mechanism based on your scenario:

Scenario	Recommended solution
Keep data private and block unauthorized access	Set Bucket ACL to `private`, which is the default configuration.
Authorize multiple users to access a specific bucket	Use Bucket Policy.
Centrally manage all resources that a user can access	Attach RAM Policy to the user.
Share resources with other Alibaba Cloud accounts	Use Bucket Policy or Use a RAM role for cross-account access to OSS.
Give multiple applications or teams different access to the same bucket	Use Access Point to provide an independent endpoint and policy for each application or team.
Centrally set permission boundaries in multi-account scenarios, such as enforcing Block Public Access	Use Control Policy.
Publish static resources that anyone can read	Set Bucket ACL to `public-read` and use Hotlink protection to prevent unauthorized use of the resources. This configuration does not take effect if Block Public Access is enabled for the account or the bucket.
Prevent data exposure caused by a misconfiguration	Enable Block Public Access. Public authorization configured through an ACL or a bucket policy no longer takes effect.
Access OSS from browser-side JavaScript	configure CORS rules for the bucket. CORS controls browser cross-origin access only and does not grant or deny access permissions.

How OSS evaluates permissions

OSS evaluates each request against the permission control mechanisms that apply to it: ACLs, bucket policies, Resource Access Management (RAM) policies, Resource Directory control policies, and access point policies (AP policies). Each mechanism is described in Permission control methods.

OSS uses a different authorization process for each request type:

Signed requests — After OSS validates the signature, it evaluates the Resource Directory control policy (if any), the RAM policy, the bucket policy, and the ACL.
Anonymous requests — OSS evaluates whether the Resource Directory control policy (if any), the bucket policy, and the ACL allow public access.

Every evaluation returns one of the following results:

Allow — A policy explicitly grants access.
Explicit Deny — A policy explicitly denies access. An Explicit Deny takes the highest priority.
Implicit Deny — No policy grants access, so the request is denied.

When you configure more than one mechanism, the following rules apply:

Multiple policy types — You can use a bucket policy, a RAM policy, and a control policy together. OSS evaluates all applicable policies and allows the request only when every applicable policy allows it. A control policy sets a permission boundary rather than granting access by itself.
Object ACL priority — An object ACL takes higher priority than the bucket ACL. If you do not specify an object ACL, the object inherits the bucket ACL.
Access point requests — When a user accesses a bucket through an access point, the merged evaluation result of the RAM policy and the bucket policy must be Allow, and the AP policy must also be Allow.
Block Public Access — When Block Public Access is enabled, public authorization configured through an ACL or a bucket policy no longer takes effect.

For the complete authorization process, see Details of OSS authorization.

Permission control methods

ACL

An ACL controls whether an OSS resource is public or private through predefined permission levels.

Bucket ACL controls the default access permissions of a bucket, and object ACL controls the permissions of a single object and takes higher priority. If you do not specify an object ACL, the object inherits the bucket ACL. The following table describes the supported permission levels.

Permission level	Applies to	Effect
`private`	Bucket ACL and object ACL	The data is private. Only the resource owner or authorized users can access the data.
`public-read`	Bucket ACL and object ACL	Anyone can read the data. Only the resource owner or authorized users can write the data.
`public-read-write`	Bucket ACL and object ACL	Anyone can read and write the data.
`default`	Object ACL	The object inherits the bucket ACL.

An ACL supports only predefined permission levels and cannot specify authorized principals or conditions. For fine-grained control, use a bucket policy or a RAM policy.

Bucket policy

Bucket Policy is an authorization policy configured on a bucket. It defines who can access the resources in that bucket. A bucket policy can authorize RAM users, other Alibaba Cloud accounts, and anonymous users, and can impose conditions such as IP address, VPC, and time restrictions.

A single bucket policy can authorize multiple users to access the same bucket. You do not need to configure a separate policy for each user.

Tutorials: Dual access control with VPC and bucket policies | Share data across departments based on a bucket policy

RAM policy

RAM Policy is an authorization policy attached to a user identity. It defines which OSS resources that user can access, and is suitable for centrally managing the permissions of a user or an application across multiple buckets.

OSS provides system policies such as AliyunOSSFullAccess and AliyunOSSReadOnlyAccess that you can use directly, and also supports custom policies. RAM roles enable cross-account access and STS temporary authorization.

Tutorials: Use a RAM role for cross-account access to OSS | Control OSS access with RAM policies

Control policy

A control policy is an access control policy based on the resource hierarchy in Resource Directory, such as folders or members, and is mainly used to define permission boundaries. In multi-account management scenarios, a custom control policy can centrally enforce restrictions on the bucket security policies of member accounts, such as requiring Block Public Access to be enabled. For details, see Control Policy.

Access Point

Access Point provides an independent access endpoint for a bucket. When multiple applications or teams need to access the same bucket with different permissions, create a separate access point for each party and use an access point policy (AP policy) to manage the permissions of that party. This approach avoids maintaining complex rules in a single bucket policy.

Each access point has an independent endpoint, AP policy, and network restriction configuration. A request that arrives through an access point is evaluated against the AP policy in addition to the RAM policy and the bucket policy. For the evaluation rules, see How OSS evaluates permissions.

Temporary access

Two methods provide temporary access to OSS resources:

STS temporary authorization — A RAM role enables cross-account access and STS temporary authorization.
Signed URL — A signed URL provides higher security than hotlink protection, because the Referer field in an HTTP request header can be forged.

Compare permission control methods

The following table compares the permission control methods that OSS provides:

Method	Configuration location	Management perspective	Granularity and conditions	Configuration requirements
ACL	On a bucket or on a single object	Resource-centric: whether a resource is public or private	Predefined permission levels only. Cannot specify authorized principals or conditions.	Only the bucket owner can set or modify a bucket ACL.
Bucket policy	On a bucket	Resource-centric: who can access the resources in the bucket	Authorized principals, actions, resources, and conditions such as IP address, VPC, and time restrictions	Simpler to configure than a RAM policy, and configurable graphically in the console. Bucket owners can grant access permissions directly without RAM operation permissions.
RAM policy	On a RAM identity	Identity-centric: which OSS resources an identity can access	Actions and resources for the identity, with optional conditions. System policies and custom policies are both supported. Does not require the `Principal` element.	Requires RAM operation permissions.
Control policy	On each level of the resource hierarchy in a resource directory, such as a folder or a member	Organization governance-centric: centrally restrict permission boundaries across the entire resource directory	Permission boundaries for member accounts, with optional conditions. Does not require the `Principal` element.	Managed in Resource Directory.
AP policy	On an access point	Endpoint-centric: separate permissions for each application or team that accesses the same bucket	Actions, resources, principals, and conditions for the requests that arrive through the access point. Network restrictions are configured separately.	Managed on the access point.

Use the following guidance to choose between the methods:

Authorizing multiple users to access the same resource — A bucket policy is more efficient. A single policy specifies the list of allowed users.
Managing all resource permissions of a single user — A RAM policy is more intuitive.
Granting anonymous access — Among the policy types, only a bucket policy supports anonymous access. An ACL also allows anonymous access at the public-read and public-read-write levels.
Restricting permissions across multiple accounts — A control policy centrally restricts permission boundaries. It constrains what member accounts can be allowed to do rather than granting access.
Separating access for multiple applications or teams — An AP policy keeps the permissions of each party independent and avoids complex rules in a single bucket policy.

Authorization policy syntax

The bucket policy, RAM policy, control policy, and AP policy are all defined in JSON format. The following table describes the core elements:

Element	Description
`Effect`	The authorization effect: `Allow` or `Deny`.
`Principal`	The authorized principal. A RAM policy and a control policy do not require this element.
`Action`	The authorized operation, such as `oss:GetObject`.
`Resource`	The scope of the authorized resources.
`Condition`	The condition under which the policy takes effect. This element is optional.

For the complete syntax description and the Action list, see OSS authorization syntax and elements.

Security protection

Block Public Access

After you enable Block Public Access, public authorization configured through an ACL or a bucket policy no longer takes effect. Existing public access permissions are ignored, and new public access permissions cannot be created. This prevents data exposure caused by a misconfiguration.

You can configure Block Public Access at the account level, which applies to all buckets, and at the bucket, access point, and object FC access point levels. Priority decreases in that order, so the account-level setting takes the highest priority.

If you store sensitive data and do not need anonymous access, enable Block Public Access at the account level.

Important

Block Public Access and public access are mutually exclusive. If Block Public Access is enabled for the account, the bucket, or the access point, a public-read ACL or a public bucket policy does not take effect. Check the Block Public Access settings before you publish resources publicly.

Hotlink protection

Hotlink protection validates the source of HTTP requests, such as the Referer and User-Agent headers, to stop unauthorized websites from referencing your OSS resources. You can configure hotlink protection by using whitelists, blacklists, or regular expressions. A whitelist allows only specified domain names, and a blacklist denies specified domain names. Use hotlink protection to prevent unauthorized use of resources such as images and videos.

The Referer field can be forged. For higher security, use a signed URL, which is a temporary access method.

Cross-origin resource sharing (CORS)

By default, a browser prevents JavaScript on a web page from accessing resources on a different domain name. After you configure CORS rules, OSS returns cross-origin headers in the response so that the browser allows the request. CORS applies to scenarios such as direct file uploads from the frontend and resource retrieval.

CORS resolves the same-origin restriction of browsers only. It does not grant or deny access permissions, so configure CORS in addition to a permission control mechanism rather than instead of one.

References

The following topics provide more information about permissions and access control in OSS: