An AccessKey pair is a credential used to authenticate your identity when you call Alibaba Cloud API operations. If an AccessKey pair is leaked, all resources that belong to your account are exposed to potential security risks, unexpected fees may be generated, and extortion attempts may occur. In severe cases, AccessKey pair leaks may even compromise Alibaba Cloud or other users. This topic describes how to handle an AccessKey pair leak to prevent identity theft risks.
Alibaba Cloud handling measures
Alibaba Cloud is committed to improving the security of cloud services and provides support in safeguarding the security of your accounts and assets. If Alibaba Cloud detects that your AccessKey pair is leaked, Alibaba Cloud immediately notifies you by using the contact information you provided. To protect your workloads and data, Alibaba Cloud restricts the use of the compromised AccessKey pair for calling Identity Management Service (IMS) API operations and Resource Access Management (RAM) API operations. However, Security Token Service (STS) API operations are not restricted. The AccessKey pair is restricted from querying, creating, or modifying the identities, AccessKey pairs, and permissions of RAM users and RAM roles. For more information, see List of operations by function for IMS, List of operations by function for RAM, and List of operations by function for STS.
You must regularly check text messages, emails, and internal messages that are sent from Alibaba Cloud and handle an AccessKey pair leak based on your business requirements at the earliest opportunity. You must also take note of abnormal changes in the cloud resources of your account to prevent impacts on your workloads.
Alibaba Cloud cannot check the security status of all your AccessKey pairs. The security responsibility sharing model prescribes that cloud security is a shared responsibility between you and Alibaba Cloud. AccessKey pairs are identity credentials that belong to your account. You are responsible for the security of your AccessKey pairs.
Handling the AccessKey pair leak for an Alibaba Cloud account
If the AccessKey pair is not in use, disable and delete the AccessKey pair on the AccessKey Pair page.
If the AccessKey pair is in use, rotate it on the AccessKey Pair page.
You can create an AccessKey pair and keep the AccessKey secret confidential. Then, you can replace the original AccessKey pair with the new pair, verify the replacement, and disable and delete the original pair.
Handling the AccessKey pair leak for a RAM user
If the AccessKey pair is not in use, disable and delete the AccessKey pair in the RAM console. For more information, see Disable an AccessKey pair of a RAM user and Delete an AccessKey pair of a RAM user.
If the AccessKey pair is in use and rotatable, rotate it at the earliest opportunity.
You can create an AccessKey pair and keep the AccessKey secret confidential. Then, you can replace the original AccessKey pair with the new pair, verify the replacement, and disable and delete the original pair. For more information, see Rotate AccessKey pairs of RAM users.
If the AccessKey pair is in use but not rotatable, follow the procedure described in the following figure to mitigate impacts of theft. After you complete the procedure, rotate the AccessKey pair at your earliest opportunity.
Step 1: Revoke permissions from the AccessKey pair
You can create a policy to revoke high-risk permissions from the leaked AccessKey pair at the earliest opportunity to minimize economic losses and impacts on your workloads. Make sure that the revocation does not affect your workloads. Do not detach the policy before you disable and delete the AccessKey pair.
High-risk permissions include the permissions to create another RAM user and grant permissions to the RAM user in the RAM console, permissions to release resources of Elastic Compute Service (ECS), ApsaraDB RDS, Object Storage Service (OSS), and Simple Log Service, and permissions to send text messages.
The following sample code provides an example of a custom policy that is used to revoke high-risk permissions. We recommend that you configure the policy based on your business requirements after you fully evaluate the impacts.
{ "Version": "1", "Statement": [ { "Effect": "Deny", "Action": [ "ram:AddUserToGroup", "ram:AttachPolicyToGroup", "ram:AttachPolicyToRole", "ram:AttachPolicyToUser", "ram:ChangePassword", "ram:CreateAccessKey", "ram:CreateLoginProfile", "ram:CreatePolicyVersion", "ram:CreateRole", "ram:CreateUser", "ram:DetachPolicyFromUser", "ram:PassRole", "ram:SetDefaultPolicyVersion", "ram:UpdateAccessKey", "ram:SetPasswordPolicy", "ram:UpdateRole", "ram:UpdateLoginProfile", "ram:UpdateUser" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "ecs:DeleteInstance", "ecs:DeleteInstances", "ecs:DeregisterManagedInstance", "ecs:ReleaseDedicatedHost" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "rds:DeleteAccount", "rds:DeleteDatabase", "rds:DeleteDBInstance", "rds:DestroyDBInstance" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "oss:DeleteBucket", "oss:DeleteObject", "oss:PutBucketAcl", "oss:PutBucketPolicy" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "log:DeleteLogStore", "log:DeleteProject", "log:PutProjectPolicy", "log:DeleteProjectPolicy" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "dysms:CreateProductNew", "dysms:CreateSmsTemplateNew", "dysms:AddSmsTemplate", "dysms:SendSms", "dysms:SendBatchSms" ], "Resource": "*" } ] }
For more information, see Create custom policies and Grant permissions to a RAM user.
We recommend that you remove all the permissions that are not required by the AccessKey pair.
Step 2: Enable MFA for the RAM user
We recommend that you enable multi-factor authentication (MFA) for all RAM users for whom console access is enabled of your Alibaba Cloud account based on best practices.
Enable MFA for all RAM users for whom console access is enabled of your Alibaba Cloud account.
For more information, see Manage console logon settings for a RAM user.
Bind MFA devices to RAM users.
For more information, see Bind an MFA device to a RAM user.
Step 3: Check for suspicious operations performed by using the AccessKey pair
Check whether the AccessKey pair has been used to perform suspicious operations and whether other identities are leaked. Take note of suspicious access IP addresses and the creation or deletion of resources that are not required by your workloads.
Method: In the RAM console, go to the AccessKey pair list of the RAM user to view the operation records in the list. Alternatively, enter the AccessKey ID on the AccessKey Pair Audit page in the ActionTrail console to query the operation records.
NoteIf operation logs of OSS and Simple Log Service are not added to ActionTrail, the operation logs must be queried by using the log feature of each service.
You must check whether other RAM users and AccessKey pairs are used for suspicious operations except for the leaked AccessKey pair. If you identify a suspicious operation, check whether the operation is performed by the owner of the RAM user or AccessKey pair. If AccessKey pair leaks occur, you can use one of the following methods based on your business requirements:
If you want to continue using the RAM user, we recommend that you immediately change the password of the RAM user and enable MFA.
If the RAM user is accidentally created or no longer required, you can delete the RAM user. After you delete the RAM user, the RAM user is moved to the recycle bin. Check whether your workloads are affected after you delete the RAM user. If your workloads are affected, you can restore the RAM user.
If suspicious operations are performed by using the AccessKey pair, perform the preceding methods to revoke permissions and then rotate the AccessKey pair.
Step 4: Check for unexpected fees
In the Expenses and Costs console, check whether any unexpected fees are generated. In addition, take preventive measures based on the results of the previous step.
Long-term solutions to AccessKey pair leaks
For more information, see Best practices for using an access credential to call API operations.