AccessKey leak response plan

Alibaba Cloud security measures

Alibaba Cloud continuously enhances the security of its cloud services and supports you in protecting your account and assets. If Alibaba Cloud detects that your AccessKey has been publicly exposed—based on external intelligence—it will promptly notify you through your registered contact channels. To safeguard your business and data, Alibaba Cloud will also apply restrictive protection to the compromised AccessKey, blocking its ability to call 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. Restrict high-risk permissions to minimize potential damage to your business and billing. Do not remove this restrictive policy until after you have disabled and deleted the AccessKey.

  Recommended high-risk permissions to restrict include the following: preventing the RAM user from creating new RAM users or granting permissions in Resource Access Management (RAM), blocking release of ECS, RDS, OSS, or SLS resources, and disabling SMS sending capabilities.

  The following example shows a custom policy that denies high-risk actions. Evaluate its impact carefully 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 for unusual activity and investigate whether other identities may also be compromised. Focus on abnormal source IP addresses and resource creation or deletion actions that are not part of normal business operations.

  Dangerous operations to investigate during the suspected leak period include the following:

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

  Using ActionTrail’s AccessKey audit feature, you can view all API calls made by a specific AccessKey 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 AccessKeys 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.