Resource Access Management:AccessKey leak response plan

Alibaba Cloud security measures

Alibaba Cloud continuously works to strengthen cloud service security and help you protect your account. If Alibaba Cloud detects that your AccessKey pair has been publicly exposed—based on external intelligence—it promptly notifies you through your registered contact channels. To safeguard your business and data, Alibaba Cloud also applies restrictive protection to the compromised AccessKey pair, blocking it from calling high-risk APIs for certain cloud services. For details, see Restrictive protection for AccessKeys.

Manual response steps for suspected leaks of an Alibaba Cloud account (root account) AccessKey

• If the AccessKey is no longer in use, go to the AccessKey management page and disable or delete it immediately.

• If the AccessKey is still in use, go to the AccessKey management page and rotate it.

  Create a new AccessKey and securely store the AccessKey secret. Replace the old AccessKey with the new one in your applications. After confirming everything works correctly, disable and delete the old AccessKey.

Manual response steps for suspected leaks of a RAM user AccessKey

• If the AccessKey is no longer in use, go to the Resource Access Management (RAM) console and disable or delete the RAM user’s AccessKey. For instructions, see Disable a RAM user's AccessKey and Delete a RAM user's AccessKey.

• If the AccessKey is in use and can be rotated immediately, rotate it as soon as possible.

  Create a new AccessKey and securely store the AccessKey secret. Replace the old AccessKey with the new one in your applications. After confirming normal operation, disable and delete the old AccessKey. For instructions, see Rotate a RAM user's AccessKey.

• If the AccessKey is in use but cannot be rotated immediately, follow the steps below to limit potential damage. Complete rotation as soon as possible afterward.

  Step 1: Reduce AccessKey permissions

  Identify your business requirements and, without disrupting current operations, quickly reduce permissions for the suspected AccessKey pair. Restrict high-risk permissions to minimize potential damage to your business and billing. Keep this restrictive policy in place until you have disabled and deleted the AccessKey pair.

  Recommended high-risk permissions to restrict: preventing the RAM user from creating RAM users or granting permissions in RAM, blocking release of ECS, RDS, OSS, or SLS resources, and disabling SMS sending.

  The following example shows a custom policy that denies high-risk actions. Evaluate its impact and adjust based on your business needs.

  {
    "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 instructions, see Create a custom policy and Manage permissions for RAM users.

  Clearly define the minimum permissions required for the AccessKey and remove all unnecessary ones.

  Step 2: Enable MFA for the RAM user

  As a best practice, enable multi-factor authentication (MFA) for all RAM users under your Alibaba Cloud account (root account) who access the console.

  1. Require MFA for RAM users logging on to the console under the root account.

     For instructions, see Manage RAM user logon settings.

  2. Bind an MFA device to the user.

     For instructions, see Bind an MFA device to a RAM user.

  Step 3: Check for abnormal AccessKey operations

  Review the AccessKey pair for unusual activity and investigate whether other identities may also be compromised. Focus on abnormal source IP addresses and resource creation or deletion actions outside normal business operations.

  Dangerous operations to investigate during the suspected leak period:

  • Identity and permission changes: creating RAM users (CreateUser), creating AccessKeys (CreateAccessKey), attaching policies (AttachPolicyToUser), and creating roles (CreateRole).

  • Resource deletion or release: deleting ECS instances (DeleteInstance), deleting RDS instances (DeleteDBInstance), and deleting OSS buckets (DeleteBucket).

  • Data exfiltration actions: modifying OSS bucket ACLs (PutBucketAcl) or bucket policies (PutBucketPolicy).

  • Abnormal API behavior: large volumes of API calls in a short time, operations from unfamiliar IP addresses or regions, or batch operations outside normal working hours.

  To check: In the Resource Access Management (RAM) console, find the RAM user’s AccessKey list and review operation records. Alternatively, go to the AccessKey audit page in the ActionTrail console and enter the AccessKey ID to query its operation history.

  ActionTrail's AccessKey audit feature shows all API calls made by a specific AccessKey pair over the past 90 days, including call time, action name, source IP address, and accessed cloud service. For instructions, see Monitor AccessKey usage with ActionTrail.

  Note

  For data-related operations not covered by ActionTrail—such as those in OSS or SLS—use the respective cloud service’s logging features to investigate.

  Also check whether other RAM users or AccessKey pairs show signs of abnormal activity beyond the known compromised key. If you find suspicious behavior, confirm with relevant personnel whether the actions were authorized. If a leak is suspected, take the following actions:

  • If the RAM user must remain active, immediately change its password and enable multi-factor authentication (MFA).

  • If the RAM user was not legitimately created or is no longer needed, delete it. Deleted RAM users go to the recycle bin. Monitor your business for impact, and restore the user quickly if needed.

  • For abnormal AccessKey activity, restrict permissions as described above, then rotate the key.

  Step 4: Check for abnormal charges

  In Expenses and Costs, review your billing for unexpected charges. Based on findings from the previous step, apply targeted protective measures for affected services.

Long-term AccessKey leak prevention strategy

See Best practices for using access credentials to call Alibaba Cloud OpenAPI.