FAQ about AccessKey pairs

What is an AccessKey pair?

An AccessKey pair consists of an AccessKey ID and an AccessKey secret, used together to authenticate programmatic requests to Alibaba Cloud.

• AccessKey ID: The public, unique identifier for your AccessKey pair.

• AccessKey secret: The private key used to sign API requests. The signature verifies the authenticity and integrity of the request. You must keep your AccessKey secret strictly confidential.

What types of AccessKey pairs are available?

• Alibaba Cloud account AccessKey pair (Not recommended)

  This AccessKey pair belongs to the Alibaba Cloud account. By default, it has full permissions on all resources under the account. If compromised, the security risk is extremely high. We strongly recommend that you do not create or use an AccessKey pair for your Alibaba Cloud account.

• RAM user AccessKey pair (Recommended)

  This AccessKey pair belongs to a RAM user, which you must create first. The AccessKey pair inherits the RAM user's permissions, enabling least-privilege access management. As a best practice, assign a separate RAM user and AccessKey pair for each independent application. This prevents excessive permissions and reduces the blast radius if credentials are compromised.

An Alibaba Cloud account AccessKey pair has full permissions on all resources under the account by default, which are equivalent to administrator permissions. It can call APIs of any cloud service, such as Short Message Service, Elastic Compute Service, and Object Storage Service, without separate authorization.

Can the same AccessKey pair be used on multiple devices at the same time?

Yes. An AccessKey pair is used only to authenticate and sign API requests and is not bound to a specific device. You can use the same AccessKey pair to call Alibaba Cloud APIs from multiple servers at the same time.

To reduce the risk of leaks, follow the principle of least privilege and assign a separate RAM user and AccessKey pair to each business application.

What information can I view after creating an AccessKey pair?

After you create an AccessKey pair, you can view its AccessKey ID, status, last-used cloud service, last-used time, and creation time. To view a RAM user's AccessKey pair information, see View the information about AccessKey pairs of a RAM user.

Can I view an AccessKey ID after it is created?

Yes.

Can I view an AccessKey secret after it is created?

No. You cannot view or modify an AccessKey secret after it is created. To reduce the risk of leaks, AccessKey secrets for Alibaba Cloud accounts and RAM users are displayed only when they are created. Store them securely.

If an AccessKey secret is lost or must be replaced, create a new AccessKey pair. After you securely store the new AccessKey secret, disable or delete the old AccessKey pair.

How do I determine whether an AccessKey pair is still in use?

View the last-used time of the AccessKey pair in the console or by calling an API to determine whether it is still in use.

• AccessKey management page

  When you log on with an Alibaba Cloud account, view the last-used time of that account's AccessKey pairs. When you log on as a RAM user, view the last-used time of that RAM user's AccessKey pairs.

• RAM console

  When you log on with an Alibaba Cloud account or as a RAM user with administrator permissions, you can view the last-used time of AccessKey pairs for all RAM users. For instructions, see View the information about AccessKey pairs of a RAM user.

• the API operation for viewing AccessKey pair last-used time

  You can call this API operation to view the last-used time of an Alibaba Cloud account or RAM user AccessKey pair.

Can I modify an AccessKey ID after it is created?

No. You cannot modify an AccessKey ID. You can only disable, enable, or delete an AccessKey pair.

Can a deleted AccessKey pair be restored?

RAM provides a recycle bin. When you delete a RAM user's AccessKey pair, it is moved to the recycle bin first. AccessKey pairs in the recycle bin can be restored.

AccessKey pairs are retained in the recycle bin for 30 days. After that period, the system automatically removes them permanently. You can also permanently delete an AccessKey pair from the recycle bin. A permanently deleted AccessKey pair cannot be restored.

For more information, see the recycle bin documentation.

What do I do if an AccessKey pair is suspected of being leaked?

Follow the procedure in Handle a suspected AccessKey pair leak.

How do I find the account that owns an AccessKey pair?

An AccessKey pair is sensitive programmatic access credential information. Alibaba Cloud does not provide a service that lets you identify the owner of an arbitrary AccessKey pair.

If you need this information, use one of the following methods to find the owner of an AccessKey pair within your authorized scope:

• Log on to the RAM console with your Alibaba Cloud account. On the Users page, enter the AccessKey ID in the search box. If you have multiple Alibaba Cloud accounts, repeat the search in each account.

• If you use the resource directory service and enable a multi-account trail in ActionTrail to deliver the operation events of all members in the resource directory service to Log Service or Object Storage Service, you can search the audit logs for AccessKey ownership information.

What do I do when I receive the error "There is a risk of leakage of this AccessKey."?

This error indicates that the AccessKey pair used for authentication is under restrictive protection. Follow the procedure in Restrictive protection of AccessKey pairs.

What do I do when I receive the InvalidAccessKeyId.AccessPolicyDenied error code?

The InvalidAccessKeyId.AccessPolicyDenied error also indicates that the AccessKey pair was denied by a network ACL policy. Handle it in the same way as AccessKeyId.AccessPolicyDenied: check the AccessKey-level and account-level network ACL policies and add the request source IP address to the allowlist. If you cannot determine the source IP address, create a new AccessKey pair for testing and troubleshooting.

Why do I still receive anomaly alerts after an AccessKey pair is disabled or deleted?

It is normal to continue receiving security alerts after an AccessKey pair is disabled or deleted. Common reasons include the following:

• Alerts are based on behavioral-model analysis: The security detection system analyzes underlying traffic and behavior models in real time. Even if an AccessKey pair has been disabled, a previous leak or attacker use can cause the system to send alerts based on historical behavior patterns.

• Differences in log query scope: By default, the console's operation records display only some write-operation logs. Calls to read operations, such as QueryAccountBalance, might not be displayed. To view complete call details, use one of the following methods:

  • Log on to the RAM console and view in-console message notifications in Security Information.

  • Use ActionTrail to query complete operation event logs.

• Handling historical alerts: If you confirmed that the AccessKey pair is disabled and a new AccessKey pair is in use, an alert might relate to a historical call event that occurred before it was disabled. You can ignore the alert after verification.

• Investigating false positives: If you suspect that an alert is a false positive, use ActionTrail to query the specific call records for the AccessKey pair and verify whether anomalous calls occurred.

Why does the IP location in an AccessKey pair anomaly alert differ from third-party query results?

IP location information in Alibaba Cloud security alerts and ActionTrail is based on Alibaba Cloud's internal IP address database. This database differs from the databases used by third-party tools such as Baidu IP lookup. Therefore, the same IP address can have different geographic locations, such as China (Hong Kong) in Alibaba Cloud and Singapore in a third-party tool.

If IP locations differ, use the result identified by Alibaba Cloud as the authoritative reference.

Why do I still receive AccessKey pair anomaly alerts after a RAM user is deleted or an Alibaba Cloud account is canceled?

The handling procedure varies by scenario:

• RAM user deleted

  The AccessKey pair in the alert might not belong to the deleted RAM user. It might be another AccessKey pair that remains enabled under the Alibaba Cloud account. Log on with the Alibaba Cloud account and open the AccessKey management page to verify the owner of the AccessKey ID in the alert, then disable or delete the anomalous AccessKey pair.

• Alibaba Cloud account canceled

  After an Alibaba Cloud account is canceled, the system automatically removes all resources under the account, including AccessKey pairs. No manual action is required. If you still receive alerts after cancellation or find that an AccessKey pair remains usable, verify the following:

  • The account cancellation process was fully completed. The system does not remove resources if the cancellation process is incomplete.

  • The AccessKey pair in the alert belongs to another Alibaba Cloud account that was not canceled.

Are calls in AccessKey pair anomaly alerts triggered by APIs or console logon?

All calls in AccessKey pair anomaly alerts are API calls and do not involve console logon.

AccessKey pairs are used only for programmatic access to Alibaba Cloud services through APIs, the CLI, and SDKs. They cannot be used to log on to the Alibaba Cloud Management Console. Console logon uses an account password or another authentication method and is unrelated to AccessKey pairs.

When a RAM user's AccessKey pair calls an API, ActionTrail logs display the RAM user name. This is normal identity tracing behavior. ActionTrail records the corresponding call event whether the API call succeeds or fails.

Does the AccessKey network ACL policy support an IP blacklist?

The AccessKey network ACL policy supports only IP whitelist mode and does not support direct IP blacklist configuration. After you enable this policy, only IP addresses in the whitelist can use the associated AccessKey pair to call APIs.

To restrict specific IP addresses from accessing cloud service resources, use one of the following methods:

• Configure an access control policy in the target cloud service console. For example, Object Storage Service supports configuring an IP blacklist in a bucket policy to deny requests from specified IP addresses.

• Enable the AccessKey network ACL policy in RAM and add only permitted IP addresses to the whitelist. IP addresses outside the whitelist are automatically denied, which indirectly provides an IP blacklist effect.

Is it normal to receive anomaly alerts after configuring an AccessKey network ACL policy?

Yes. After you enable an AccessKey network ACL policy, API calls from IP addresses outside the whitelist are blocked and return the AccessPolicyDenied error. The calls are not performed, but the security detection system still records the blocked attempts and triggers alerts.

Such an alert indicates that an untrusted IP address attempted to use your AccessKey pair to access cloud services, but the network ACL policy effectively blocked the request. This is expected security protection behavior and does not mean that the call succeeded.

What do I do if I cannot add an IP address to a RAM network ACL policy or submit the policy?

If you cannot add an IP address or submit the network ACL policy, check the following items:

• Public network policy: Make sure that the IP address format is correct. A single IP address and CIDR notation, such as 192.168.1.0/24, are supported. If you only need to restrict public network access sources, explicitly add the permitted target IP addresses instead of relying on the "Allow all public network access" option.

• Virtual private cloud policy: Enter the ID of an existing virtual private cloud. Verify the virtual private cloud ID in the VPC console. A nonexistent or incorrectly formatted virtual private cloud ID causes submission to fail.

• Network types that do not require restrictions: If you do not use a network type, such as a virtual private cloud, you can leave its policy unconfigured to avoid validation failures caused by invalid values.

Does changing a RAM user's logon name or display name change the AccessKey pair?

No. The AccessKey ID and AccessKey secret remain unchanged, and API, SDK, and CLI calls continue to work. Use the new logon name for console logon. If scripts, single sign-on, policies, or internal systems reference the old logon name, update them. Only disabling or deleting the AccessKey pair, or deleting the RAM user, invalidates the AccessKey pair.