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.

What information can I view about an AccessKey pair?

You can view an AccessKey pair's metadata, including its AccessKey ID, status, creation time, and last-used information.

Can I view an AccessKey ID after it is created?

Yes.

Can I view an AccessKey secret after it is created?

No. For security reasons, the AccessKey secret is only available to view or download at creation time. The AccessKey secret also cannot be modified. If the AccessKey secret is lost or needs to be replaced, the only option is to create a new AccessKey pair. Make sure to copy and save the new AccessKey secret before closing the creation dialog, as it cannot be retrieved afterward.

How do I check if an AccessKey pair is in use?

Check the last-used time for an AccessKey pair in the console or through the API.

• AccessKey page

  When logged in with an Alibaba Cloud account or as a RAM user, view the last-used time for your own AccessKey pairs.

• RAM console

  As a RAM administrator, view the last-used time for any RAM user's AccessKey pairs in your account. View the information about AccessKey pairs of a RAM user.

• GetAccessKeyLastUsed API operation

  Call this operation to programmatically retrieve the last-used time for an AccessKey pair.

Can I change an AccessKey ID?

No. AccessKey IDs are immutable.

Can I restore a deleted AccessKey pair?

Yes, for RAM users. When you delete a RAM user's AccessKey pair, it is moved to a recycle bin.

Deleted AccessKey pairs are retained in the recycle bin for 30 days and can be restored during this period. Once an AccessKey pair is purged, it cannot be recovered.

For more information, see Delete a RAM user's AccessKey.

What do I do if an AccessKey pair is leaked?

For more information, see AccessKey leak response plan.

How do I find which account owns an AccessKey pair?

For security reasons, Alibaba Cloud does not provide a public service to identify the owner of an AccessKey ID.

To identify the owner of an AccessKey ID within your organization, use one of the following methods:

• In the RAM console, go to the Users page and search for the AccessKey ID. If you manage multiple accounts, repeat the search in each account.

• If your organization uses Resource Directory, enable a multi-account trail in ActionTrail, then query the aggregated audit logs for the AccessKey ID to identify the owner.

Why am I getting a "There is a risk of leakage of this AccessKey" error?

Alibaba Cloud detected a potential leak and placed the AccessKey pair under restrictive protection. Resolve this by following the steps in Restrictive protection of AccessKey pairs.

Why do I still receive anomalous call alerts after disabling or deleting an AccessKey pair?

Alibaba Cloud security detection analyzes underlying traffic and behavioral models in real time. Even after an AccessKey pair is disabled, alerts may still be sent in the following cases:

• Pre-disable leakage: If the AccessKey pair was leaked or exploited before being disabled, the system continues to flag the associated anomalous behavior.

• Log query differences: The Operation Records page in the console only displays certain write operations by default. Read-type API calls (such as QueryAccountBalance) may not appear. To view complete call records, check the in-console messages on the Security Information page of the RAM console, or query ActionTrail for full audit logs.

• Historical alert handling: If you have confirmed that the AccessKey pair is disabled and a replacement is in use, the alert may relate to a historical event. After verification, you can safely disregard it.

• False positive investigation: If you suspect a false positive, use ActionTrail to query the specific call records associated with the alert and verify whether an actual anomalous call occurred.

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

The IP location information in Alibaba Cloud security alerts and ActionTrail audit logs is based on the Alibaba Cloud internal IP address database. This may differ from the geographic location shown by third-party tools such as Baidu IP lookup. For example, an IP address may be identified as Hong Kong (China) by Alibaba Cloud but shown as Singapore by a third-party tool.

Use the Alibaba Cloud identification result as the authoritative reference.

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

RAM user deleted

The AccessKey pair flagged in the alert may not belong to the deleted RAM user. It could be an AccessKey pair that is still active under the Alibaba Cloud account (root account). Log in with the root account and check the Security Information management page to identify and handle the flagged AccessKey pair.

Alibaba Cloud account deregistered

After an account is deregistered, all associated resources including AccessKey pairs are automatically cleaned up by the system. No manual action is required. If you continue to receive alerts or find that an AccessKey pair is still usable, verify that the account deregistration process was fully completed, or check whether the AccessKey pair belongs to a different account that has not been deregistered.

Are the calls in AccessKey anomaly alerts triggered through API or console login?

AccessKey pairs are used exclusively for programmatic access through API, CLI, and SDK. AccessKey pairs cannot be used for console login. All interface calls recorded in anomaly alerts are triggered through programmatic access, not through console login.

When an API is called using a RAM user's AccessKey pair, ActionTrail audit logs display the RAM user name. This is the normal identity tracing mechanism and applies regardless of whether the call succeeds or fails.

What do I do when an API call is denied by a network access restriction policy?

When a network access restriction policy is configured for an AccessKey pair or an Alibaba Cloud account, API calls from IP addresses outside the allowlist are denied. The following error codes may be returned:

• AccessKeyId.AccessPolicyDenied

• InvalidAccessKeyId.AccessPolicyDenied

Both error codes indicate that the AccessKey pair is blocked by an access restriction policy. To resolve this issue:

1. Log in to the RAM console and check the AccessKey-level and account-level network access restriction policies.

2. Add the source IP address to the allowlist in the applicable policy.

3. If the issue persists, create a new AccessKey pair for testing to determine whether the restriction is at the AccessKey level or the account level.

Does the AccessKey network access restriction policy support IP blacklists?

No. The AccessKey network access restriction policy supports allowlist mode only and does not support direct IP blacklist configuration.

To restrict specific IP addresses from accessing cloud services such as OSS, consider the following alternatives:

• Configure an IP blacklist in the target cloud service console. For example, configure an IP blacklist in the OSS console for OSS-specific restrictions.

• Enable the AccessKey network access restriction policy in RAM and add only the permitted IP addresses. This allowlist-based approach effectively blocks access from all IP addresses that are not on the list.

Is it normal to receive anomalous call alerts after configuring AccessKey network access restrictions?

Yes. After a network access restriction policy is enabled, API calls from IP addresses outside the allowlist are blocked and return an AccessPolicyDenied error. However, the blocked attempt itself still triggers a security alert.

Receiving an alert does not mean the call succeeded. It indicates that an unauthorized IP address attempted to access the resource and the attempt was effectively blocked. This is expected security protection behavior.

What do I do if adding an IP address or VPC to the RAM network access restriction policy fails?

If the policy configuration cannot be submitted, check the following:

• Public network policy: Ensure the IP address format is correct. If you need to restrict public network access, explicitly add the target IP addresses rather than relying on the "Allow all public network access" option.

• VPC policy: The VPC ID must correspond to an existing VPC instance. Verify the VPC ID in the VPC console. An incorrect or nonexistent VPC ID causes submission failures.

• Unnecessary policy types: If you do not use a specific network type (for example, if you have no VPC), skip configuring the corresponding policy to avoid unnecessary validation errors.

Troubleshooting unexpected denials

Message: The specified parameter "AccessKeyId.AccessPolicyDenied" is not valid.

Message: code: 400, Specified access key denied due to access policy. 

Does changing a RAM user’s logon/display name change the AccessKey?

No. The AccessKey ID/Secret remain unchanged, and API/SDK/CLI calls still work. Console logon requires the new logon name. Update scripts, SSO, policies, or internal systems that reference the old logon name. Only disabling/deleting the AccessKey or deleting the RAM user invalidates it.