All Products
Search
Document Center

Cloud Config:Alibaba Cloud platform security best practices

Last Updated:Nov 17, 2025

This topic describes the default rules for Alibaba Cloud platform security best practices. Based on Alibaba Cloud's experience in security administration, these rules continuously detect risky configurations across key security areas, including account security, cloud resource security, network security, data security, backup and recovery, and log audits.

Rule name

Rule description

Enable MFA for Alibaba Cloud accounts

An Alibaba Cloud account is considered compliant if multi-factor authentication (MFA) is enabled. Enabling MFA for your Alibaba Cloud account helps reduce the risk of account theft.

Do not use an AccessKey for the Alibaba Cloud account

An Alibaba Cloud account is considered compliant if it does not have an AccessKey. The AccessKey of an Alibaba Cloud account has extensive permissions that cannot be restricted. A leaked AccessKey can have catastrophic consequences. Instead, use the AccessKey of a RAM user and implement proper access control.

Use HTTPS for public API requests in API Gateway

An API Gateway API is considered compliant if it uses HTTPS for public requests to encrypt data in transit. This rule does not apply to APIs that are restricted to internal network calls, which are considered not applicable.

Enable HTTPS encryption for accelerated domain names

An accelerated domain name is considered compliant if HTTPS is enabled to encrypt data in transit.

Set an automatic snapshot policy for ECS disks

An ECS disk is considered compliant if an automatic snapshot policy is configured. Disks that are not in use, do not support automatic snapshot policies, or are mounted on ACK clusters for non-persistent use are considered not applicable. When an automatic snapshot policy is enabled, Alibaba Cloud automatically creates snapshots for disks at specified times. This lets you quickly recover from security events such as virus intrusions or ransomware attacks.

Enable Security Center protection for running ECS instances

An instance is considered compliant if the Security Center plugin is installed on the host for security protection. This rule does not apply to instances that are not running, which are considered not applicable.

Use ECS instances in a VPC

An ECS instance is considered compliant if its network type is virtual private cloud (VPC). If a parameter is specified, the instance is compliant if it is in a specified VPC. Using ECS instances in a VPC helps implement basic network isolation and ensures the network security of your cloud environment.

Use a key pair to log on to Linux hosts

A Linux host is considered compliant if a key pair is used for logon. An SSH key pair is a secure and convenient logon authentication method that is resistant to brute-force attacks.

Prevent security groups from opening risky ports to all IP addresses for specified protocols

A security group is considered compliant if its inbound rule for a specified protocol does not open specified risky ports to the 0.0.0.0/0 CIDR block. This practice reduces the risk of brute-force attacks on server logon passwords. If a detected risky port is rejected by a higher-priority authorization policy, the security group is also considered compliant. Security groups used by cloud products or virtual operators are considered not applicable. By default, this rule detects risky ports 22 and 3389.

Do not enable public access for MongoDB instances or set the whitelist to allow access from any source

A MongoDB instance is considered compliant if public network access is disabled or the whitelist is not set to allow access from any source. This helps prevent attacks, including brute-force attacks, and reduces the risk of data leaks.

Enable log backup for MongoDB instances

A MongoDB instance is considered compliant if log backup is enabled. Log backups allow you to restore data to any point in time within the retention period.

Disable public-read-write ACL for OSS buckets

An OSS bucket is considered compliant if its access control list (ACL) is not set to public-read-write. If an OSS bucket has public-read-write permissions, any visitor can write to the bucket, which creates a risk of malicious data injection. This permission should be disabled.

Disable public-read ACL for OSS buckets

An OSS bucket is considered compliant if its ACL is not set to public-read. The public-read permission increases the risk of data leaks. This permission should be disabled.

Set an access policy for public OSS buckets and grant no permissions to anonymous accounts

An OSS bucket with public read or write permissions is considered compliant if an authorization policy is configured that does not grant read or write permissions to anonymous accounts. This reduces the risk of data leaks. OSS buckets with private permissions are considered not applicable.

Do not enable public access for PolarDB instances or set the IP whitelist to all network segments

A PolarDB instance is considered compliant if public network access is disabled or the IP whitelist is not set to allow access from all IP addresses. This helps prevent attacks, including brute-force attacks, and reduces the risk of data leaks.

Set SSL encryption for PolarDB clusters

A PolarDB cluster is considered compliant if SSL encryption is enabled to protect data in transit.

Set the log backup retention period for PolarDB clusters to more than 30 days

A PolarDB cluster is considered compliant if its log backup retention period is at least the specified number of days. The default value for this parameter is 30 days. A cluster is considered non-compliant if log backup is disabled or the retention period is shorter than the specified number of days. Log backups allow you to restore data to any point in time within the retention period.

Do not grant super administrator (Admin) permissions to RAM users

A configuration is considered compliant if no RAM user, RAM user group, or RAM role is granted Admin permissions where Resource is set to * and Action is set to *. To follow the principle of least privilege, do not grant these permissions.

Enable MFA for RAM users

A RAM user with console access is considered compliant if MFA is enabled. Enabling MFA helps reduce the risk of account theft.

Ensure no idle AccessKeys exist for RAM users

A RAM user's AccessKey is considered compliant if it has been used within the number of days specified by the parameter. The default value is 90 days. If an AccessKey is confirmed to be idle, you should disable it promptly.

Do not configure a public IP address for RDS instances

An RDS instance is considered compliant if it is not configured with a public IP address. You should not configure Direct Internet Access for RDS instances in a production environment. Doing so makes them vulnerable to attacks, including brute-force attacks, which can lead to data leaks.

Enable log backup for RDS instances

An RDS instance is considered compliant if log backup is enabled. Read-only instances are considered not applicable. Log backups allow you to restore data to any point in time within the retention period.

Enable SSL for RDS instances and use a specified TLS version

An RDS instance is considered compliant if SSL is enabled and the TLS version used is one of the versions specified by the parameter. This practice encrypts data in transit.

Do not enable public access for Redis instances or set the whitelist to allow access from any source

A Redis instance is considered compliant if public network access is disabled or its whitelist is not set to allow access from any source. Enabling public access from any source makes Redis instances vulnerable to attacks, including brute-force attacks, which can lead to data leaks.

Set TLS or SSL encryption for Redis instances

A Redis instance is considered compliant if SSL encryption is enabled to protect data in transit.

Enable incremental backup for Redis instances

A Redis instance is considered compliant if incremental backup is enabled. This rule applies only to Tair or Enterprise Edition instances. Instances of other types are considered not applicable. Incremental backups allow you to restore data to any point in time within the retention period.

Do not configure the access control list of a CLB instance to all address segments

A Classic Load Balancer (CLB) instance is considered compliant if its access control list does not contain a 0.0.0.0/0 entry. For services other than HTTP and HTTPS, you should enable access control, configure a whitelist, and ensure that the whitelist rules do not include 0.0.0.0/0.

Ensure CLB instance listeners do not include risky ports

A CLB instance is considered compliant if its listeners do not monitor specified risky ports. You should not forward ports such as 22 and 3389 to the internet to reduce the risk of attacks, including brute-force attacks.

Add an HTTPS listener to a CLB instance

A CLB instance is considered compliant if an HTTPS listener is configured on a specified port to encrypt data in transit. If a CLB instance has only TCP or UDP listeners, it is considered not applicable. The default port is 443. You can separate multiple ports with commas. The instance is considered compliant if an HTTPS listener is enabled on any of the specified ports.

Ensure the network ACL of a VPC does not open risky ports

A VPC is considered compliant if the source address in its inbound rules for TCP or UDP protocols on ports 22 and 3389 is not 0.0.0.0/0. This practice reduces the risk of brute-force attacks on server logon passwords.