This topic provides an overview of Multi-Level Protection Scheme (MLPS) 2.0 and describes the default rules that are included in the ClassifiedProtectionPreCheck compliance package template.
What is MLPS 2.0?
MLPS 2.0 stipulates the national cybersecurity standards in China. The Chinese government officially released MLPS 2.0 on May 13, 2019 and officially implemented MLPS 2.0 on December 1, 2019.
Important changes in MLPS 2.0
Information systems in the cloud can be evaluated.
On the basis of the network and information systems of MLPS 1.0, MLPS 2.0 adds specifications for cloud computing platforms, big data platforms, IoT platforms, mobile computing systems, and industrial control systems. The specifications fully consider the diversity and complexity of the business carried by current enterprise information systems.
The information systems built by cloud tenants are independently evaluated.
In MLPS 1.0, the level of a cloud platform on which enterprise resources are hosted determines the level of an information system that a cloud tenant builds on the platform. As cloud services become increasingly complex and flexible, cloud tenants have increased control over hosted resources. Therefore, from MLPS 2.0 on, the information systems built by cloud tenants on cloud platforms are independently evaluated.
Continuous security evaluation is emphasized.
In MLPS 1.0, the compliance of a system is evaluated only once. After the evaluation is complete, you cannot continuously monitor the system to check whether the system is compliant with the specifications. MLPS 2.0 integrates the requirement for continuous compliance into the specifications to guide and supervise enterprises so that they can build information systems with sustainable security capabilities. MLPS 2.0 is based on the policy-centered protection, detection, and response (PPDR) model, and allows enterprises to construct a three-dimensional and in-depth defense system that is trusted, controllable, and manageable. The defense system must be constructed based on trusted authentication and with access control as the core.
Characteristic
Description
Trusted
Construct a trusted execution environment for business systems based on trusted computing. To prevent users from being impersonated and prevent viruses and intrusions, users, platforms, and applications must be trusted. A trusted environment ensures the security and reliability of the business systems. This way, business systems can run as expected without being interrupted by unexpected processes.
Controllable
Enable subjects to control the access behavior of objects based on access control to ensure that all access activities are controllable. Controlled access prevents both internal and external attacks. Controlled access also protects information systems from unauthorized operations and unauthorized resource access. This ensures that information systems are secure and controllable.
Manageable
Construct a management platform that allows administrators to manage permissions in a centralized and hierarchical manner, and grant minimal permissions to users for better system management. This can help users focus on other operations. This also ensures that information systems are secure and can be managed.
MLPS 2.0 uses the "one center, triple protection" design philosophy for cybersecurity technology. One center refers to the security management center. Triple protection refers to the secure computing environment, the security zone border, and the secure communications network.
The security management center must support centralized management operations for system management, security management, and audit management. The protection mode must be changed from passive to active, from static to dynamic, from single-point to all-around, and from extensive to intensive.
Triple protection requires enterprises to use security devices and technologies to implement security measures such as identity authentication, access control, intrusion prevention, data integrity, confidentiality, and personal information protection. Triple protection enables all-around protection for cloud platforms.
The following table describes the differences between MLPS 1.0 and MLPS 2.0.
MLPS 1.0 | MLPS 2.0 |
In-depth defense with attack prevention, attack response, and security audit. | All-around defense with active prevention, security authentication, threat detection, and comprehensive audit. |
If the evaluation scores are higher than 60, the official evaluation is passed. The official evaluation for MLPS 1.0 Level 3 must be performed on a yearly basis, and the official evaluation for MLPS 1.0 Level 4 must be performed at an interval of six months. | If the evaluation scores reach 70, the official evaluation is passed. Annual evaluations are required for both MLPS 2.0 Level 3 and MLPS 2.0 Level 4. |
Five difficulties for information systems in the cloud to conform to MLPS 2.0
MLPS 2.0 focuses on continuous compliance supervision. Annual evaluations are required for both MLPS 2.0 Level 3 and MLPS 2.0 Level 4. Information systems in the cloud have difficulties in conforming to MLPS 2.0 because resources are hosted on the cloud. The following table describes the difficulties.
Difficulty | Description |
Unclear evaluation objects | Some concepts of the virtualized IT infrastructure are different from those of the traditional IT infrastructure. The evaluation of complex cloud configurations is difficult. |
Non-centralized resource management | If a cloud platform does not support configuration management databases (CMDBs), you have to endure a cumbersome process of providing evidence and demonstrating information systems in the cloud to authoritative agencies during the repeated evaluation and rectification. |
Less control over the system data | Resources are hosted on the cloud. You must obtain security audit data from the cloud platform if MLPS 2.0 requires management logs and compliance reports as evidence. |
Unable to perform self-evaluation by writing code | In the past, all enterprises had on-premises CMDBs and could write code to monitor and evaluate configurations on their own before the official evaluation. However, resources are now hosted on the cloud. Evaluating configurations on their own by writing code requires continuous configuration synchronization from the cloud, which incurs high costs. |
Separated deployment of a business system | In a hybrid cloud model, a business system is separately deployed on the cloud and on on-premises machines. In this case, you must perform self-evaluation, scanning, monitoring, or detection twice. These processes incur high manpower costs and require a long period of time. |
Continuous monitoring on cloud platforms
To resolve the preceding difficulties, Alibaba Cloud provides the classified protection precheck feature in Cloud Config free of charge. This feature facilitates the self-evaluation and remediation of your business.
Cloud Config processes the specifications of MLPS 2.0 as rules, continuously monitors resource configuration changes, evaluates resource compliance in real time, and triggers alerts for non-compliance. This way, enterprises can continuously monitor the compliance of information systems.
ClassifiedProtectionPreCheck
The ClassifiedProtectionPreCheck compliance package template contains rules that correspond to the requirements that are listed in MLPS 2.0. For more information, see the following table.
The ClassifiedProtectionPreCheck compliance package template provides a common compliance evaluation framework. You can specify input parameters for rules and configure remediation settings to efficiently create compliance packages that meet your requirements in specific business scenarios. If resources are evaluated as compliant, the resources conform only to the compliance rules, but not necessarily to all the requirements of relevant laws, regulations, and industry standards.
Rule name | Rule description | Requirement No. | Requirement description |
ecs-instances-in-vpc | Checks whether the network type of each Elastic Compute Service (ECS) instance is VPC if the vpcIds parameter is not set. If so, the evaluation result is Compliant. Checks whether each ECS instance is deployed in one of the specified virtual private clouds (VPCs) if the vpcIds parameter is set. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices have sufficient capabilities to process business requests during peak hours. |
8.1.2.1 | Plan network zones and allocate addresses to each zone for efficient management and control. | ||
8.1.2.1 | Do not deploy important network zones at borders. Take reliable technical measures to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communications lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communications. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communications. | ||
rds-instances-in-vpc | Checks whether the network type of each ApsaraDB RDS instance is VPC if the vpcIds parameter is not set. If so, the evaluation result is Compliant. Checks whether each ApsaraDB RDS instance is deployed in one of the specified VPCs if the vpcIds parameter is set. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices have sufficient capabilities to process business requests during peak hours. |
8.1.2.1 | Plan network zones and allocate addresses to each zone for efficient management and control. | ||
8.1.2.1 | Do not deploy important network zones at borders. Take reliable technical measures to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communications lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communications. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communications. | ||
redis-instance-in-vpc | Checks whether the network type of each ApsaraDB for Redis instance is VPC if the vpcIds parameter is not set. If so, the evaluation result is Compliant. Checks whether each ApsaraDB for Redis instance is deployed in one of the specified VPCs if the vpcIds parameter is set. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices have sufficient capabilities to process business requests during peak hours. |
8.1.2.1 | Plan network zones and allocate addresses to each zone for efficient management and control. | ||
8.1.2.1 | Do not deploy important network zones at borders. Take reliable technical measures to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communications lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communications. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communications. | ||
mongodb-instance-in-vpc | Checks whether the network type of each ApsaraDB for MongoDB instance is VPC if the vpcIds parameter is not set. If so, the evaluation result is Compliant. Checks whether each ApsaraDB for MongoDB instance is deployed in one of the specified VPCs if the vpcIds parameter is set. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices have sufficient capabilities to process business requests during peak hours. |
8.1.2.1 | Plan network zones and allocate addresses to each zone for efficient management and control. | ||
8.1.2.1 | Do not deploy important network zones at borders. Take reliable technical measures to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communications lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communications. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communications. | ||
polardb-dbcluster-in-vpc | Checks whether the network type of each PolarDB cluster is VPC if the vpcIds parameter is not set. If so, the evaluation result is Compliant. Checks whether each PolarDB cluster is deployed in one of the specified VPCs if the vpcIds parameter is set. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices have sufficient capabilities to process business requests during peak hours. |
8.1.2.1 | Plan network zones and allocate addresses to each zone for efficient management and control. | ||
8.1.2.1 | Do not deploy important network zones at borders. Take reliable technical measures to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communications lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communications. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communications. | ||
eip-bandwidth-limit | Checks whether the available bandwidth of each elastic IP address (EIP) is greater than or equal to a specified value. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the bandwidth of each network component meets your requirements during peak hours. |
slb-loadbalancer-bandwidth-limit | Checks whether the available bandwidth of each Server Load Balancer (SLB) instance is greater than or equal to a specified value. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the bandwidth of each network component meets your requirements during peak hours. |
sg-risky-ports-check | Checks whether the inbound CIDR block of a security group is set to 0.0.0.0/0. If not, the evaluation result is Compliant. Checks whether the specified high-risk ports are disabled if the inbound CIDR block of a security group is set to 0.0.0.0/0. If so, the evaluation result is Compliant. | 8.1.3.1 | Allow only cross-border access requests and data packets transmitted over the controlled interfaces of border devices. |
8.1.4.4 | Specify access methods or CIDR blocks to restrict the network access of terminals. | ||
sg-public-access-check | Checks whether the port range -1/-1 and the authorized CIDR block 0.0.0.0/0 are not specified at the same time if the inbound authorization policy of a security group is set to Allow. If so, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
slb-no-public-ip | Checks whether no public IP address is associated with each SLB instance. If so, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
rds-public-access-check | Checks whether each ApsaraDB RDS instance has a public endpoint. If not, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
ecs-instance-no-public-ip | Checks whether no public IPv4 address or EIP is associated with each ECS instance. If so, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
oss-bucket-public-read-prohibited | Checks whether the access control list (ACL) policy of each Object Storage Service (OSS) bucket denies read access from the Internet. If so, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
redis-public-access-check | Checks whether 0.0.0.0/0 is added to the IP address whitelist of each ApsaraDB for Redis instance. If not, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
mongodb-public-access-check | Checks whether 0.0.0.0/0 is added to the IP address whitelist of each ApsaraDB for MongoDB instance. If not, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
polardb-public-access-check | Checks whether 0.0.0.0/0 is added to the IP address whitelist of each PolarDB cluster. If not, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
slb-acl-public-access-check | Checks whether an IP address whitelist is configured for each SLB instance and 0.0.0.0/0 is not added to the IP address whitelist. If so, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
rds-instance-enabled-security-ip-list | Checks whether an IP address whitelist is configured for each RDS instance and 0.0.0.0/0 is not added to the IP address whitelist. If so, the evaluation result is Compliant. | 8.1.3.1 | Be able to control or check access from unauthorized devices to the internal network. |
8.1.3.2 | Set access control rules at network borders or between network zones based on access control policies. By default, controlled interfaces accept only communication requests allowed by the rules. | ||
actiontrail-enabled | Checks whether at least one active trail exists in ActionTrail. If so, the evaluation result is Compliant. | 8.1.3.5 or 8.1.4.3 | Periodically back up audit logs to protect them from unexpected deletion, modification, or overwriting. |
ram-user-mfa-check | Checks whether multi-factor authentication (MFA) is enabled for each RAM user. If so, the evaluation result is Compliant. | 8.1.4.1 | Use a combination of two or more of the following techniques to authenticate user identities: password, cryptography technique, and biotechnology. A cryptography technique must be used in each combination. |
slb-listener-https-enabled | Checks whether an HTTPS listener is enabled for a specified port on each SLB instance. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during transmission, including authentication data and important business data, audit data, configuration data, video data, and personal data. |
cdn-domain-https-enabled | Checks whether HTTPS is enabled for each domain name accelerated by Alibaba Cloud CDN. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during transmission, including authentication data and important business data, audit data, configuration data, video data, and personal data. |
oss-bucket-server-side-encryption-enabled | Checks whether the Encryption Method parameter of the server-side encryption feature is set to OSS-Managed for each OSS bucket. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during storage, including authentication data and important business data, audit data, configuration data, video data, and personal data. |
8.1.4.8 | Use cryptography techniques to ensure the confidentiality of important data during storage, including authentication data, important business data, and important personal data. | ||
ecs-disk-encrypted | Checks whether the encryption feature is enabled for each ECS data disk. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during storage, including authentication data and important business data, audit data, configuration data, video data, and personal data. |
rds-high-availability-category | Checks whether the edition of each ApsaraDB RDS instance is High-availability. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide the features of backing up and restoring important data locally. |
8.1.4.9 | Provide the features of backing up important data over a communications network to a remote destination site in real time. | ||
8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. | ||
rds-multi-az-support | Checks whether each ApsaraDB RDS instance is deployed across multiple zones. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. |
oss-zrs-enabled | Checks whether the zone-redundant storage (ZRS) feature is enabled for each OSS bucket. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. |
rds-connectionmode-safe-enabled | Checks whether the proxy mode is enabled for each ApsaraDB RDS for SQL Server instance. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. |