Handle AccessKey pair leaks and control access to objects to protect sensitive data of objects in buckets - Data Security Center

The data detection and response feature provides two measures to handle AccessKey pair leaks: AccessKey pair management and bucket governance. This way, you can control access to objects and buckets based on IP addresses and sensitivity levels. This helps defend against data leaks and attacks and ensures data security. For example, you can disable affected AccessKey pairs to prevent unauthorized access or create a stricter access control policy for affected objects. This topic describes how to handle AccessKey pairs that are leaked or potentially leaked. This topic also describes how to control access to buckets and objects in buckets.

Prerequisites

The information about leaked AccessKey pairs and the bucket objects that are accessed by using the leaked AccessKey pairs is queried. For more information, see View leaked AccessKey pairs and unusual access alerts.

Background information

For more information about the working principles and limits of AccessKey pair leak detection and unusual access alerting, see Overview

Solution description

Solution	Handling method	Scenario	Description
Handling of AccessKey pair leaks	Add an AccessKey pair to the whitelist	False positive: If an AccessKey pair is marked as leaked but is considered risk-free, you can add the AccessKey pair to the whitelist. Known risk: In some cases, an AccessKey pair may be intentionally disclosed for a specific purpose. For example, some automated scripts need to access public resources. In this case, you can add the AccessKey pair to the whitelist.	You can add an AccessKey pair to the whitelist in the Data Security Center (DSC) console. If you configure alert notifications for an AccessKey pair, DSC no longer sends alert notifications after the AccessKey pair is added to the whitelist. To view an alerts, log on to the DSC console and choose Data Detection and Response > OSS Data Leak (AccessKey Pair Scenarios). For more information, see View leaked AccessKey pairs and unusual access alerts.
	Disable an AccessKey pair	Suspected AccessKey pair abuse: If you confirm that an AccessKey pair is obtained by an unauthorized third party but you require more time to assess the leak risk and scope, we recommend that you immediately disable the AccessKey pair. Temporary access restriction: When you handle security events, you may need to temporarily restrict the permissions of an account to ensure system security. In this case, you can disable an AccessKey pair.	You can disable an AccessKey pair on the AccessKey pair management page in the Resource Access Management (RAM) console.
	Delete an AccessKey pair	Clear leak: If you confirm that an AccessKey pair is leaked and potentially abused, we recommend that you delete the AccessKey pair at the earliest opportunity to prevent further security events. AccessKey pair no longer required: If an application or a service associated with an AccessKey pair is offline or key rotation is ongoing, we recommend that you delete the old AccessKey pair to avoid potential security risks. Compliance: To meet compliance requirements, you may need to periodically replace or delete old credential information to reduce security risks.	To delete an AccessKey pair, log on to the RAM console or notify the owner of the AccessKey pair.
	Rotate an AccessKey pair for a RAM user	Log on to the Key Management Service (KMS) console and configure automatic rotation for AccessKey pairs of RAM users to reduce risks of AccessKey pair leaks. For more information, see Manage and use RAM secrets.	If the AccessKey pair of a RAM user is leaked after you activate KMS and configure automatic rotation for the AccessKey pair in KMS, you can log on to the DSC console to enable quick rotation. The rotation duration is 10 minutes.
Bucket permission governance (Block)	Configure the access control list (ACL) for a bucket	You can set the Bucket ACL parameter to Public Read, Public Read/Write, or Private. This parameter specifies whether a user or a user group can access a bucket and the operations that a user or a user group can perform on the bucket. The operations include read and write. You can perform coarse-grained access control on a bucket. For example, you can restrict access to objects in a bucket to specific users.	You can log on to the DSC console and set the Bucket ACL parameter to Private for a bucket to allow only the bucket owner to access the bucket.
	Allow specific IP addresses to access a bucket	You can allow specific IP addresses or IP addresses from a specific CIDR block to access a bucket. The additional access restriction improves security. Examples: You can allow only internal IP addresses of an enterprise to access a bucket in which sensitive data is stored. You can allow only IP addresses from specific countries or regions to access data in a bucket based on compliance requirements. You can deny unauthorized access from public networks to reduce the attack surface of a bucket and improve data security.	DSC provides a policy template to restrict access from specific IP addresses. You can use the policy template to deny access to a specific bucket from a CIDR block from which a leaked AccessKey pair is used to initiate the most requests. You can create a custom policy to implement fine-grained access control based on your business requirements. For more information, see Overview. For more information about how to create a custom policy, see Create custom policies and Grant permissions to a RAM user.
	Allow only authorized users to access sensitive objects	If a bucket contains sensitive objects, you can perform additional access control to allow only authorized users to access the objects. Examples: Compliance: To comply with data protection laws and regulations, strictly restrict access to specific types of objects such as personally identifiable information and financial reports. Fine-grained access control: In a multi-user environment, configure different levels of access permissions to allow specific users to only access or modify the authorized objects. Core asset protection: Apply a stricter access control policy to highly sensitive or high-value objects to ensure that the objects are not inappropriately disclosed.	DSC provides a policy template to restrict access to sensitive objects. You can use the template to deny access from the owner account of the leaked AccessKey pair to objects of specific sensitivity levels in a bucket. You can create a custom policy to implement fine-grained access control based on your business requirements. For more information, see Overview. For more information about how to create a custom policy, see Create custom policies and Grant permissions to a RAM user.

Handler description

If you enable the data detection and response feature as an Alibaba Cloud account:
- By default, the Alibaba Cloud account has full permissions to handle AccessKey pair leaks that occur within the Alibaba Cloud account and the RAM users of the Alibaba Cloud account, and perform related bucket governance.
- If multi-account management is enabled and AccessKey pair leaks occur within a member, contact the owner of the member to handle the leaks and perform related bucket governance.
If you enable the data detection and response feature as a RAM user to whom the AliyunYundunSDDPFullAccess policy is attached:
- The RAM user has full permissions to handle AccessKey pair leaks that occur within the RAM user and perform related bucket governance.
- If AccessKey pair leaks occur within other RAM users, the RAM user can only add the AccessKey pairs to the whitelist. For other handling options, the RAM user can perform the following operations:
  - Contact the account administrator to handle an AccessKey pair leak.
  - Contact the account administrator to grant the required permissions.
    For example, if the RAM user wants to disable an AccessKey pair, the ListAccessKeys and UpdateAccessKey policies must be attached to the RAM user. If the RAM user wants to enable quick rotation for an AccessKey pair, the AliyunKMSSecretAdminAccess policy must be attached to the RAM user. If the RAM user wants to create a bucket policy and attach the policy to specific RAM users, the CreatePolicy and AttachPolicyToUser policies must be attached to the RAM user.
    For more information about RAM policies, see RAM authorization.
  - Contact the owners of the other RAM users to handle an AccessKey pair leak and perform related bucket governance.

Handle an AccessKey pair leak

Log on to the DSC console.
In the left-side navigation pane, choose Data Detection and Response > OSS Data Leak (AccessKey Pair Scenarios).
On the OSS Data Leak (AccessKey Pair Scenarios) page, click numbers in the AccessKey Pair Leaks section to view the information about leaked AccessKey pairs.
Find an AccessKey pair that you want to manage and click Manage AccessKey Pair in the Actions column. In the Manage AccessKey Pair panel, select a handling method.
You can also find an AccessKey pair that you want to manage from the alert list in the lower part of the OSS Data Leak (AccessKey Pair Scenarios) page, and click Details in the Actions column. On the Alert Details page, click Manage AccessKey Pair next to AccessKey Pair Status to go to the Manage AccessKey Pair panel.

Add an AccessKey pair to the whitelist

Click Add to Whitelist. In the message that appears, click OK.

If you configure alert notifications for an AccessKey pair, DSC no longer sends alert notifications after the AccessKey pair is added to the whitelist.

Disable an AccessKey pair

Click Disable. You are directed to the AccessKey Pair page of the RAM console. On the page, disable the AccessKey pair. For more information, see Disable an AccessKey pair of a RAM user.

If you do not have the permissions to disable the AccessKey pair, the system prompts you to obtain the required permissions. You can also contact the owner of the AccessKey pair to disable the AccessKey pair.

Rotate an AccessKey pair

Click Rotate. DSC checks the rotation policy that you configured for RAM secrets in KMS and performs immediate rotation. The rotation duration is 10 minutes.

If you do not activate KMS, the system prompts you to connect to KMS and configure periodic AccessKey pair rotation.

For more information, see Manage and use RAM secrets.

If you do not have the permissions to rotate the AccessKey pairs of other RAM users, you can contact the owners of the AccessKey pairs to rotate the AccessKey pairs.

Mark the handling status of an AccessKey pair

If you disable or delete an AccessKey pair in the RAM console, the operation result is not automatically synchronized to the DSC console. You must manually mark the handling status of the AccessKey pair in the DSC console.

Important

The status marking operation does not trigger actual operations. Before you mark the status, make sure that the relevant handling operation is complete.

Log on to the DSC console.
In the left-side navigation pane, choose Data Detection and Response > OSS Data Leak (AccessKey Pair Scenarios).
On the OSS Data Leak (AccessKey Pair Scenarios) page, find the AccessKey pair that you want to manage in the alert list and select a state from the drop-down list in the AccessKey Pair Status column to mark the handling status of the AccessKey pair.

Restrict access to a bucket

Log on to the DSC console.
In the left-side navigation pane, choose Data Detection and Response > OSS Data Leak (AccessKey Pair Scenarios).
In the lower part of the OSS Data Leak (AccessKey Pair Scenarios) page, find the bucket that you want to manage in the alert list and click Details in the Actions column.
In the Details section of the bucket, click Manage next to Bucket Governance Progress.
In the Manage panel, restrict access to objects in the bucket.

Configure the ACL for a bucket

Click Configure next to Bucket ACL and set Bucket ACL to Private.

Private specifies that only the bucket owner can perform read and write operations on objects in the bucket. Other users cannot access the objects in the bucket. In this case, Processed is displayed for Bucket ACL.

If you set Bucket ACL to Public Read or Public Read/Write, Unhandled is displayed for Bucket ACL.

Restrict access from IP addresses

In the Blocked IP Addresses section, configure a custom policy and attach the policy to the owner account of the AccessKey pair.

Click Copy to obtain the policy template.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:*"
      ],
      "Resource": [
        "acs:oss:*:*:sddp-acl-xxxx-read-1/*"
      ],
      "Condition": {
        "IpAddress": {
          "acs:SourceIp": [
            "2xx.xxx.xxx.xxx"
          ]
        }
      }
    }
  ]
}

Click Configure. You are directed to the Permissions > Policies > Create Policy page of the RAM console. On the page, click JSON.

Replace the policy document on this tab with the policy document in the template. You can modify the policy document based on your business requirements. The following table describes the policy. For more information, see RAM policies.

Parameter	Description
Effect	The effect of the policy. The value is fixed as Deny to deny access from specific IP addresses.
Action	The operation to be performed on the bucket.
Resource	The object that the policy covers. By default, the value is the name of the bucket.
Condition	The condition for the policy to take effect. `IpAddress` specifies that the type of the condition is IP addresses, and `acs:SourceIp` specifies the IP addresses on which the policy takes effect. The IP address that most frequently accesses the bucket is automatically specified as the value of acs:SourceIp. The template indicates that the specified IP addresses cannot access all objects in the `sddp-acl-unittest-public-read-1` bucket.

Click Next to edit policy information, configure Name and Description for the policy, and then click OK.
Attach the policy to the owner account of the AccessKey pair. For more information, see Grant permissions to a RAM user.
Go back to the Manage panel, click the icon next to Blocked IP Addresses, and then select Processed from the drop-down list.
The operation result in the RAM console is not automatically synchronized to the DSC console. After the authorization is complete, you must manually update the handling status in the DSC console.

Restrict access to sensitive objects

In the Inaccessible Sensitive Files section, repeat the preceding operations that you performed to restrict access from IP addresses. Then go back to the Manage panel and select a state from the drop-down list next to Inaccessible Sensitive Files.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:*"
      ],
      "Resource": [
        "acs:oss:*:*:sddp-acl-xxxx-read-1/*"
      ],
      "Condition": {
        "StringEquals": {
          "oss:ExistingObjectTag/SensitiveLevelTagForSDDP": [
            "4"
          ]
        }
      }
    }
  ]
}

You can modify the policy document based on your business requirements. The following table describes the policy. For more information, see RAM policies.

Parameter	Description
Effect	The effect of the policy. The value is fixed as Deny to deny access to specific sensitive objects.
Action	The operation to be performed on the bucket.
Resource	The object that the policy covers. By default, the value is the name of the bucket.
Condition	`IpAddress` specifies that the type of the condition is IP addresses and `oss:ExistingObjectTag/SensitiveLevelTagForSDDP` specifies the sensitivity level tag `SensitiveLevelTagForSDDP` on which the policy takes effect. The value of the highest sensitivity level from the scan result is automatically specified for oss:ExistingObjectTag/SensitiveLevelTagForSDDP. The value 4 indicates the sensitivity level S4. The template indicates that the owner account of the AccessKey pair cannot access the objects of the S4 sensitivity level in the `sddp-acl-unittest-public-read-1` bucket. Mappings between values and sensitivity levels: 1 for the S1 sensitivity level, 2 for the S2 sensitivity level, 3 for the S3 sensitivity level, and 4 for the S4 sensitivity level. The preceding mapping pattern applies to other values and sensitivity levels. Important If you configure Object Storage Service (OSS) synchronization, the value of the `SensitiveLevelTagForSDDP` tag from the scan result is automatically synchronized to the objects after a sensitive data identification task is complete. For more information, see Synchronize sensitivity level tags to OSS objects. If you do not configure OSS synchronization, you must manually add the sensitivity level tag `SensitiveLevelTagForSDDP` to the objects. For more information, see Add tags to an object.

References

An AccessKey pair is used to authenticate your identity when you call Alibaba Cloud API operations. If an AccessKey pair is leaked, all resources within your account may be at risk, unexpected fees may be generated, and ransom-driven attacks may occur. In severe cases, an AccessKey pair leak may even cause harm to Alibaba Cloud or other users. For more information about how to handle AccessKey pair leaks, see Solutions to AccessKey pair leaks and Credential security solutions.
By default, the Bucket ACL parameter for OSS resources, including buckets and objects, is set to Private. In this case, only the resource owner or authorized users can access the resources. If you want to perform fine-grained access control on third-party users, you can create and attach different policies to different users to grant permissions on your OSS resources to the users.
OSS supports four types of policies to control access to objects in buckets. For more information, see RAM policies, Bucket policies, Bucket ACLs, and Object ACLs.