If the AccessKey pairs of individual or enterprises users are leaked, users that are not supposed to have access to Object Storage Service (OSS) resources may be able to manage the resources and threaten data security. To address this issue, OSS provides a wide array of best practices for security for you to implement data security and protection.

Notice The following best practices are a set of general rules, not a compressive set of security solutions. These best practices are for reference only. We recommend that you remain conscious about data security and take the necessary precautions and preventative measures.

Block public access

Unless your business requires everyone, including anonymous visitors, be able to read data from and write data to your OSS resources (including buckets and objects), do not set the access control list (ACL) of the buckets or the objects to public read or public read/write. Description of public read/write and public read:

  • Public read/write: Anyone, including anonymous users, can perform read and write operations on objects in the bucket.
    Warning All Internet users can access objects in the bucket and write data to the bucket. If you set the ACL to public read/write, the objects may be accessed unpredictably, which can lead to spiraling costs. If a user uploads prohibited data or information, you may be held liable. Therefore, we recommend that you do not set the File ACL parameter to public read/write except in special cases.
  • Public read: Only the bucket owner can perform write operations on the objects in the bucket. Other users, including anonymous users, can perform only read operations on the objects in the bucket.
    Warning All Internet users can access objects in the bucket. This may result in unexpected access to the data in your bucket and out-of-control costs. Exercise caution when you set your bucket ACL to public read.

To reduce security risks caused by public access, we recommend that you set the ACL of a bucket or an object to private. After you set the ACL to private, only the bucket owner can read and write the bucket and the objects in the bucket.

You can use multiple methods to set the ACL of a bucket or an object to private. For more information, see Configure the ACL feature for a bucket and Configure ACL for objects.

Do not include plaintext AccessKey pairs in code or store encrypted AccessKey pairs locally

Plaintext AcceccKey pairs in code may be leaked with the code. AccessKey pairs locally encrypted and stored are also not secure because encrypted and decrypted content is stored in the memory and the data in the memory can be stored in another device. Mobile apps and applications on PCs are prone to these risks. To obtain decrypted data, attackers need only to use technologies such as injection, API hooking, and dynamic debugging.

On the server, you can use managed secret plug-ins for Alibaba Cloud SDKs to avoid plaintext AcceccKey pairs in code. This way, you can prevent AccessKey pairs from being leaked with source code or compiled code. For more information about managed secret plug-ins for Alibaba Cloud SDKs, see Managed secret plug-ins for Alibaba Cloud SDKs.

Notice This method does not apply to clients. Do not embed AccessKey pairs in clients.

Access OSS by using a RAM user

An Alibaba Cloud account has permissions to call all API operations. If you use the AccessKey pair of an Alibaba Cloud account, security risks may occur. We recommend that you create and use a RAM user to call API operations or perform routine O&M.

You can create RAM users and grant the RAM users different permissions to control their access to your resources. RAM allows you to keep your Alibaba Cloud account and password strictly confidential in scenarios where multiple users in your enterprise need to collaboratively manage cloud resources. It also allows you to grant the users the minimum required permissions, which ensures high security. For more information about how to create a RAM user, see Create a RAM user.

After you create a RAM user, you can use a RAM policy to grant permissions to the RAM user. This way, you can manage your users, such as employees, systems, and applications, and control the resources that can be accessed by these users. For example, you can use the following RAM policy to prevent specified RAM users from accessing a bucket named examplebucket and objects or directories in examplebucket.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "oss:*",
            "Resource": [
                "acs:oss:*:*:examplebucket",
                "acs:oss:*:*:examplebucket/*"
            ]
        }
    ]
}

You can also use RAM policies to prevent RAM users from deleting a directory in a bucket, or authorize RAM users to only read resources in a bucket. For more information about RAM policy examples, see Common examples of RAM policies.

Enable MFA

MFA is an easy-to-use and effective authentication method. When MFA is enabled, a dynamic authentication code generated by an MFA device is required in addition to your username and password when you attempt to log on to the Alibaba Cloud Management Console. This way, unauthorized access can be blocked to ensure security of your account in the event of password leaks.

You can choose to enable MFA for an Alibaba Cloud account. For more information, see Enable an MFA device for an Alibaba Cloud account. You can choose to enable MFA for a RAM user. For more information, see Enable an MFA device for a RAM user.

Access OSS by using a temporary access credential provided by STS

You can use Security Token Service (STS) to generate a temporary credential to allow a user to access your OSS resources within the specified period. This way, you do not need to share your AccessKey pair or risk the security of your OSS resources.

For more information about how to use STS to grant temporary permissions to access OSS, see Use a temporary access credential provided by STS to access OSS in OSS Development Guide.

Configure bucket policies

You can configure bucket policies to authorize other users to access specified OSS resources for a bucket. For example, you can configure bucket policies to authorize other accounts to access or manage all resources or part of resources in your bucket. You can also configure bucket policies to grant different permissions to different RAM users of the same account.

When you configure bucket policies, follow the principle of least privilege (PoLP) to minimize security risks.

  • Do not authorize users to access all resources in your bucket

    To avoid excessive permissions and illegal access, we recommend that you do not specify all resources in your bucket and you grant permissions only on required resource paths.

  • Do not allow anonymous access

    Anonymous accounts can be used to access OSS if an endpoint and a bucket name are provided. However, endpoints can be enumerated, and bucket names can be obtained from the URLs of objects they are authorized to access. Therefore, anonymous access increases security risks.

  • Specify Action

    When you configure a bucket policy in the OSS console, Action that provides four authorization operations is only a convenient method for users to configure policies, and the specified action may not meet your business requirements. We recommend that you grant only required permissions to users by using Advanced Settings. For example, read-only permissions include oss:ListObjects and oss:GetObject. In most scenarios, only the oss:GetObject permission is required if you want to download an object.

  • Enable HTTPS for access

    You can enable HTTPS to resolve issues such as man-in-the-middle attacks and domain hijacking. In addition, if you use Google Chrome to view an HTTPS website, HTTP resources of the website cannot be loaded by default. Make sure that you enable HTTPS, which is the most cost-effective way to resolve various risks.

  • Specify source IP addresses

    If the IP addresses used to access OSS resources are specified and can be enumerated, we recommend that you configure IP addresses.

For example, you can use a bucket policy to authorize the Test RAM user to download all objects in the log directory in examplebucket by using OSS SDKs or command-line tool ossutil.

policy