If an AccessKey pair is leaked, unauthorized users can access your Object Storage Service (OSS) resources and threaten data security. This page describes best practices for reducing that risk.
These are general security measures, not a complete security solution. They are provided for reference and may not fit every business scenario. Stay alert to data security threats and apply the preventative measures appropriate for your environment.
Use temporary access credentials (recommended)
Security Token Service (STS) generates temporary access credentials that expire after a specified period, so you do not need to share your AccessKey pair. This ensures higher data security.
For details, see Use temporary credentials provided by STS to access OSS.
Access OSS through a RAM user
The Alibaba Cloud account AccessKey pair has permissions on all API operations. Using it directly for OSS operations is high-risk. Instead, create Resource Access Management (RAM) users with only the permissions each user or application needs.
RAM lets you keep your Alibaba Cloud account credentials confidential in multi-user environments and enforce the principle of least privilege (PoLP). For details, see Create a RAM user.
After creating a RAM user, attach a RAM policy to control which resources the user can access. For example, the following policy denies all OSS operations on examplebucket and the objects it contains:
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": "oss:*",
"Resource": [
"acs:oss:*:*:examplebucket",
"acs:oss:*:*:examplebucket/*"
]
}
]
}For more policy examples, see Common examples of RAM policies.
Keep AccessKey pairs out of code
Embedding AccessKey pairs in source code exposes them whenever code is shared or compiled binaries are distributed. Even locally encrypted credentials are not safe: decrypted values pass through memory and can be extracted using techniques such as injection, API hooking, and dynamic debugging. Mobile apps and desktop applications are especially vulnerable to these attacks.
The right approach depends on where your code runs:
Server-side applications: Use managed secret plug-ins for Alibaba Cloud SDKs. These plug-ins retrieve credentials at runtime, keeping secrets out of your source code and compiled output. For details, see Managed secret plug-in for Alibaba Cloud SDKs.
Client applications (mobile and desktop): Do not embed AccessKey pairs in clients. Use STS temporary credentials instead — see Use temporary access credentials (recommended).
Set bucket and object ACLs to private
Do not set the access control list (ACL) of buckets or objects to public-read or public-read-write unless your business requires it. The effects of each ACL setting are:
| ACL | Who can read | Who can write | Risk |
|---|---|---|---|
| public-read-write | All users, including anonymous | All users, including anonymous | Data leaks, unexpectedly high fees, and potential infringement if prohibited content is written |
| public-read | All users, including anonymous | Bucket owner only | Data leaks and unexpectedly high fees |
| private | Bucket owner only | Bucket owner only | Lowest risk (recommended) |
Before changing an ACL to private, verify that your applications are not affected. For how to change ACLs, see Bucket ACLs and Configure ACL for objects.
Enable MFA
Multi-factor authentication (MFA) requires both a password and a dynamic verification code from an MFA device when signing in to the Alibaba Cloud Management Console. This blocks unauthorized console access even if a password is leaked.
To enable MFA for your Alibaba Cloud account, see Bind an MFA device to an Alibaba Cloud account.
To enable MFA for a RAM user, see Bind an MFA device to a RAM user.
Configure bucket policies with least privilege
Bucket policies grant other users or accounts access to specific OSS resources. Follow the principle of least privilege when configuring them:
Limit resource paths. Grant permissions only on the specific paths required, not on the entire bucket.
Avoid anonymous access. Endpoints can be enumerated, and bucket names can be obtained from object URLs. Anonymous access significantly increases exposure.
Specify only required actions. The preset options in the OSS console cover broad categories. Use Advanced Settings to grant only what is needed. For example, read-only access typically requires
oss:ListObjectsandoss:GetObject. In most download scenarios, onlyoss:GetObjectis needed.Enable HTTPS. HTTPS prevents 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.
Restrict source IP addresses. If the IP addresses that access OSS resources are fixed and can be enumerated, add them to the bucket policy as an additional access control.
The following example grants the Test RAM user permission to download all objects in the log directory of examplebucket using OSS SDKs or ossutil:
