Object Storage Service:Reduce the risks of unauthorized access caused by AccessKey pair leaks

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

  All Internet users can access objects in the bucket and write data to the bucket. This may result in data leaks and unexpectedly high fees. If a user writes prohibited data or information to objects in 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 read data from objects in the bucket.

  Warning

  All Internet users can access objects in the bucket. This may result in data leaks 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.

You can use multiple methods to set the object ACL or bucket ACL to private. For more information, see Bucket ACLs and Configure ACL for objects.

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

Plaintext AccessKey pairs in code may be leaked together with the code. AccessKey pairs that are 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 computers are prone to these risks. To obtain decrypted data, attackers need only to use technologies such as injection, API hooking, and dynamic debugging.

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

Access OSS by using a RAM user

The AccessKey pair of an Alibaba Cloud account has permissions on all API operations. Using these credentials to perform operations in OSS is a high-risk operation. We recommend that you 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 manage access to your resources. RAM helps you keep your Alibaba Cloud account and password strictly confidential in scenarios in which multiple users in your enterprise need to collaboratively manage cloud resources. It also allows you to grant the users the minimum required permissions to ensure data security. For more information, 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 manage the resources that can be accessed by these users. For example, you can use the following RAM policy to prevent specific RAM users from accessing a bucket named examplebucket and objects or directories in the examplebucket bucket.

{
    "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 to authorize RAM users to only read resources in a bucket. For more information, see Common examples of RAM policies.

Enable MFA

Multi-factor authentication (MFA) is an easy-to-use and effective authentication method. If you enable MFA, your username and password and a dynamic verification code that is generated by an MFA device are required when you log on to the Alibaba Cloud Management Console. This way, unauthorized access can be blocked to ensure the security of your Alibaba Cloud account if password leaks occur.

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

Access OSS by using temporary access credentials provided by STS

You can use Security Token Service (STS) to generate temporary access credentials to authorize a RAM user to access your OSS resources within a specific period of time. This way, you do not need to share your AccessKey pair. This ensures higher data security.

For more information about how to access OSS by using temporary access credentials provided by STS, see Use temporary credentials provided by STS to access OSS.

Configure bucket policies

You can configure bucket policies to grant other users the permissions to access specific OSS resources in a bucket. For example, you can configure bucket policies to grant other accounts the permissions 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 reduce security risks.

• Do not grant users the permissions to access all resources in your bucket

  To prevent excessive permissions and illegal access, we recommend that 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 that the accounts can access. Therefore, anonymous access increases security risks.

• Specify Action

  When you configure a bucket policy in the OSS console, Action which 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 the 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, the HTTP resources of the website cannot be loaded by default. Make sure that you enable HTTPS. HTTPS is the most cost-effective method to resolve various issues.

• Specify source IP addresses

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

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