Resource Access Management:Solutions to AccessKey pair leaks

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 provides restrictive protection for the compromised AccessKey pair. This way, the compromised AccessKey pair cannot be used to call high-risk API operations of specific cloud services. For more information, see Restrictive protection for 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 Resource Access Management (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.

  1. 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.

  2. 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.

  Note

  If 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.